conflicting libraries at runtime

Поиск
Список
Период
Сортировка
От Joe Conway
Тема conflicting libraries at runtime
Дата
Msg-id 3EA9BA94.4070704@joeconway.com
обсуждение исходный текст
Ответы Re: conflicting libraries at runtime
Re: conflicting libraries at runtime
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: How about an am_superuser GUC parameter (non-settable)?
Следующее
От: "Sumaira Ali -"
Дата:
Сообщение: Re: Putting code in main of src/backend/main/main.c