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 по дате отправления: