conflicting libraries at runtime - Mailing list pgsql-hackers

From Joe Conway
Subject conflicting libraries at runtime
Date
Msg-id 3EA9BA94.4070704@joeconway.com
Whole thread Raw
Responses Re: conflicting libraries at runtime  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: conflicting libraries at runtime  (Peter Eisentraut <peter_e@gmx.net>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: How about an am_superuser GUC parameter (non-settable)?
Next
From: "Sumaira Ali -"
Date:
Subject: Re: Putting code in main of src/backend/main/main.c