From owner-freebsd-stable@FreeBSD.ORG Mon Oct 14 20:32:16 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F34F3E2 for ; Mon, 14 Oct 2013 20:32:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 340CD256E for ; Mon, 14 Oct 2013 20:32:16 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b47b:4d6a:b4fe:4826] (unknown [IPv6:2001:7b8:3a7:0:b47b:4d6a:b4fe:4826]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9BD705C44; Mon, 14 Oct 2013 22:32:10 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_7A577A69-AB79-43C4-92E9-A95FCAFB480D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: runtime linker on 9.x/i386: clang vs. gcc From: Dimitry Andric In-Reply-To: <525C1A5C.2030605@aldan.algebra.com> Date: Mon, 14 Oct 2013 22:31:56 +0200 Message-Id: References: <525C1A5C.2030605@aldan.algebra.com> To: Mikhail T. X-Mailer: Apple Mail (2.1510) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 20:32:16 -0000 --Apple-Mail=_7A577A69-AB79-43C4-92E9-A95FCAFB480D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 14, 2013, at 18:22, Mikhail T. 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... >=20 > One example of this is reported in 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). >=20 > Another example is xorg-server, which, for me, can not load some of = the drivers because they complain of missing symbols: >=20 > (EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: = /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol = "DRIFinishScreenInit" >=20 > 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 = ) with the = stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg = executable and the libdri.so remain clang-compiled. >=20 > 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. >=20 > 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=3Drevision&revision=3D312583 for = the diff. -Dimitry --Apple-Mail=_7A577A69-AB79-43C4-92E9-A95FCAFB480D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iEYEARECAAYFAlJcVMMACgkQsF6jCi4glqPgIwCfV8ySjwjATOvzrJnFiTlTyQe8 AcAAoMe/plJAhIGxuA2wkxXUFAwpDt+b =eMtO -----END PGP SIGNATURE----- --Apple-Mail=_7A577A69-AB79-43C4-92E9-A95FCAFB480D--