On Oct 14, 2013, at 18:22, Mikhail T. <mi+thun at aldan.algebra.com>
wrote:> 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?
There are many possibilities here, and you might be running into
multiple different problems, but the X.org failures look familiar to me.
There is a problem when clang does tail-call optimization on i386 with
PIC in effect, and it emits GOT relocations for the tail-called
functions, instead of PLT relocations. In some scenarios, such as with
the way X.org does lazy dynamic linking, this can cause problems. See
also http://llvm.org/PR15086 (which I unfortunately did not get much
response on).
For now, a workaround is to recompile the affected .so files with
-fno-optimize-sibling-calls (if you are optimizing). This is also the
approach taken for the X.org ports, see
http://svnweb.freebsd.org/ports?view=revision&revision=312583 for the
diff.
-Dimitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20131014/64d1b32b/attachment.sig>