conflicting libraries at runtime

From: Joe Conway <mail(at)joeconway(dot)com>
To: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: conflicting libraries at runtime
Date: 2003-04-25 22:45:40
Message-ID: 3EA9BA94.4070704@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I know this is a bit off-topic, but I was hoping someone can point me in
the right direction. I've been spinning my wheels on this for a while now.

I'm having trouble with PL/R giving me a SIGSEGV *only* on Red Hat 9.
I've isolated it (at least the symptom) down to this: on RH9, a call to
re_compile_fastmap() uses /lib/tls/libc.so.6 instead of the
compiled-into-R function with the same name. The /lib/tls/libc.so.6
version of the function calls re_compile_fastmap_iter() which then
generates the SIGSEGV. I have tested a very simple standalone app, on
the same box, also linked to the same libR.so, and it uses R's builtin
re_compile_fastmap() (which has no re_compile_fastmap_iter() function).
The standalone app works fine. These calls happen during the early
initialization process of R.

R itself works fine and passes all of it's regression tests.

I've tested *exactly* the same PL/R code on RH8 and RH7.3 boxen with no
problems. gdb shows that on those machines the libR version of
re_compile_fastmap() is used, just like the standalone app on RH9.

Any ideas? I'd be happy to provide more info (off list) if anyone wants it.

Thanks,

Joe

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sumaira Ali - 2003-04-26 01:37:44 Re: Putting code in main of src/backend/main/main.c
Previous Message Tom Lane 2003-04-25 22:35:01 How about an am_superuser GUC parameter (non-settable)?