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
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)? |