Re: dlopen(3) and symbol conflicts

[christos%astron.com@localhost (Christos Zoulas)]

In article <1m1inl8.el84nlm69h57M%manu%netbsd.org@localhost>,
Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
>Hello
>
>I use dlopen(3) to load a api.so, which depends on libglustefs.so. The
>later embeds its own uuid_compare symbol which is binary incompatible
>with NetBSD's libc uuid_compare. The thing explodes because when I call
>uuid_compare(), the libc version is used insteadof libglusterfs.so's
>one.
>
>The problem is specific to dlopen(3): when linking at build time, libc's
>uuid_compare is overriden and everything goes fine. Is it a problem on
>how api.so is linked? Or how dlopen() is invoked? Or a bug in dlopen(3)?
>
>$ ldd api.so
>        -lgfapi.0 => /autobuild/install/lib/libgfapi.so.0
>        -lgfrpc.0 => /autobuild/install/lib/libgfrpc.so.0
>        -lexecinfo.0 => /usr/lib/libexecinfo.so.0
>        -lelf.1 => /usr/lib/libelf.so.1
>        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
>        -lc.12 => /usr/lib/libc.so.12
>        -lglusterfs.0 => /autobuild/install/lib/libglusterfs.so.0
>        -lz.1 => /usr/lib/libz.so.1
>        -lrt.1 => /usr/lib/librt.so.1
>        -lintl.1 => /usr/lib/libintl.so.1
>        -lpthread.1 => /usr/lib/libpthread.so.1
>        -lcrypto.8 => /usr/lib/libcrypto.so.8
>        -lcrypt.1 => /lib/libcrypt.so.1
>        -lgfxdr.0 => /autobuild/install/lib/libgfxdr.so.0
>
>$ nm /autobuild/install/lib/libglusterfs.so|grep uuid_compare 
>00067c20 T uuid_compare

Did you use dlopen() with RTLD_GLOBAL?

christos