Date: Mon, 14 Oct 2013 22:31:56 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Mikhail T. <mi+thun@aldan.algebra.com> Cc: stable@FreeBSD.org Subject: Re: runtime linker on 9.x/i386: clang vs. gcc Message-ID: <B4BCF2B5-5B37-47E1-BCB7-A0159E249E10@FreeBSD.org> In-Reply-To: <525C1A5C.2030605@aldan.algebra.com> References: <525C1A5C.2030605@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Oct 14, 2013, at 18:22, Mikhail T. <mi+thun@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iEYEARECAAYFAlJcVMMACgkQsF6jCi4glqPgIwCfV8ySjwjATOvzrJnFiTlTyQe8 AcAAoMe/plJAhIGxuA2wkxXUFAwpDt+b =eMtO -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B4BCF2B5-5B37-47E1-BCB7-A0159E249E10>