Hello!
I'm seeing a strange problem with clang-compiled binaries on 9.x/i386
system. Here it is: if a shared library A needs a symbol provided by a
shared library B, libA will fail to load into a process even if the
executable is linked with libB. The only fix (work-around?) is to relink
libA to explicitly depend on libB. A temporary work-around is to use
LD_PRELOAD to list all of the necessary libBs...
One example of this is reported in ports/180473
<http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/180473> -- the
libprldap6.so refuses to load because of the symbols it needs from
libnspr4.so. For some reason, the fact, that -lnspr4 is linked into the
executable (seamonkey or thunderbird), is not sufficient... As the
ticket suggests, using gcc46 (Mozilla rejects gcc-4.2.x nowadays)
instead of clang solves the problem (though an even better solution is
in place since this weekend).
Another example is xorg-server, which, for me, can not load some of the
drivers because they complain of missing symbols:
(EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so:
/opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol
"DRIFinishScreenInit"
The DRIFinishScreenInit is provided by libdri.so, which the server also
loads... But, somehow, that is not sufficient. Rebuilding
vboxvideo_drv.so (provided by emulators/virtualbox-ose-additions
<http://www.freshports.org/emulators/virtualbox-ose-additions>) with the
stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg
executable and the libdri.so remain clang-compiled.
I am not prepared to argue, whether that's a "right" or "wrong" behavior
-- but it certainly is inconsistent, because it is only manifested on
i386 and only when the compiler is clang.
Any thoughts?
-mi
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
