From owner-freebsd-ports@FreeBSD.ORG Wed Feb 22 01:22:13 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A088106566C; Wed, 22 Feb 2012 01:22:13 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD5CC8FC1A; Wed, 22 Feb 2012 01:22:12 +0000 (UTC) Received: by qaea17 with SMTP id a17so8656488qae.13 for ; Tue, 21 Feb 2012 17:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=owSZAoMsJnf8937RbxmgSR5zjWvOordcPLkHj+LgmPo=; b=YYYmTq28SpSHO1JjfB0SY+YJHNH9mhGsrtQNnY2zqJPCG1u5g18qy+nUTelJrHPIk8 H6A1WaDtx+xSPZowBXqUkRDlJ/pYqoSgHDcCqcFDQy3Dwu+WhqcJV82/hGDaE7efQ2mG 4Gq4IHJPePyTG2Vy0HGN13YtebHsY2HjguYRI= Received: by 10.229.137.144 with SMTP id w16mr18023500qct.8.1329873378995; Tue, 21 Feb 2012 17:16:18 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id dm7sm62067977qab.5.2012.02.21.17.16.18 (version=SSLv3 cipher=OTHER); Tue, 21 Feb 2012 17:16:18 -0800 (PST) Date: Tue, 21 Feb 2012 20:16:12 -0500 From: Alexander Kabaev To: Steve Kargl Message-ID: <20120221201612.2968c810@kan.dyndns.org> In-Reply-To: <20120221194259.GA21185@troutmask.apl.washington.edu> References: <20120221182850.GA20768@troutmask.apl.washington.edu> <20120221185754.GL55074@deviant.kiev.zoral.com.ua> <20120221194259.GA21185@troutmask.apl.washington.edu> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/XFKAIIJj1u5yzyeZ2sdzvhl"; protocol="application/pgp-signature" Cc: Konstantin Belousov , freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: rtld or lang/gcc cannot find libgcc_s.so.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 01:22:13 -0000 --Sig_/XFKAIIJj1u5yzyeZ2sdzvhl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 21 Feb 2012 11:42:59 -0800 Steve Kargl wrote: > On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > > >=20 > > > troutmask:kargl[210] halfspace > > > /lib/libgcc_s.so.1: version GCC_4.6.0 required > > > by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] > > >=20 > > > (Note, the annoying absense of a newline character after the error > > > message, which is a completely different issue.) > > >=20 > > > I see this problem on both freebsd-i386 and freebsd-amd64. > > >=20 > > > troutmask:kargl[212] ldd ~/bin/halfspace > > > /home/kargl/bin/halfspace: > > > liblapack.so.4 =3D> /usr/local/lib/liblapack.so.4 > > > (0x2008c3000) libblas.so.2 =3D> /usr/local/lib/libblas.so.2 > > > (0x201463000) libgfortran.so.3 > > > =3D> /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 > > > =3D> /lib/libm.so.5 (0x201a70000) libgcc_s.so.1 > > > =3D> /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 > > > =3D> /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 > > > =3D> /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] ldconfig -r > > > | grep libgcc_s 29:-lgcc_s.1 =3D> /lib/libgcc_s.so.1 > > > 723:-lgcc_s.1 =3D> /usr/local/lib/gcc46/libgcc_s.so.1 > > >=20 > > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or=20 > > > the lang/gcc port is no longer providing sufficient information > > > for rtld to choose the correct library. > > >=20 > > > I have reverted revisions 230784, 299768, and 229508 (and > > > various combinitions of these revisions) from rtld-elf. The > > > result does not change the above error. > > >=20 > > > I can work around the problem by specifying -static during > > > the building of my programs. Or, I can work around the > > > problem by *explicitly* adding '-rpath /usr/local/lib' to the > > > command line, which I have never had to do. > > >=20 > > I highly suspect that you just happen to not need a symbol from the > > newest namespace before. > >=20 > > The thing to look first is the library search path in the ld.so > > hints, which is output at the second line of ldconfig -r. I think > > that you have /lib before /usr/local/lib/gcc46 in your setup. This > > guess is confirmed by the numeration of the two instances of gcc_s > > above. Either change the config, or use -rpath. AFAIR, ldconfig -m > > adds the directory at the end of the search list. >=20 > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > that this is a heads up for gerald@. lang/gcc is used by > the ports collections to build a large number of other > ports, so others are likely to hit this issue. >=20 > I tried reading rtld.c to see where the issue lies. One > possibility seems to be a change in rtld.c (lines 4012-13) > to remember the version mismatch, then continuing the search=20 > to see if another library with the same name but different > location matches. After exhausting the list of directories > in the search path, either an error is reported or a match > has been found. Note, I'm still trying to parse and understand > the rtld.c code, so may be what I'm suggesting is not=20 > feasible. >=20 This was suggested before in a slightly different context and at the time I was not big fan of the idea. With more ports starting to use out of tree GCC, maybe we need to revisit the idea. There are corner cases that I do not know how to handle in this approach: what happens if we have mapped system libgcc_s.so.1 already which did satisfy all the requirements and later a new library gets mapped in dynamically and requires symbol versions from newer GCC? Going with this suggestion will likely involve substantial changes into rtld dependency walking code - we'll need to make a graph traversal and collect all the version information from all the libraries that might satisfy the search before doing the final pass of loading the winning candidates, which implies at least two dependency tree passes. And, given the above, it won't even give us what we want anyway as long as there's dlopen in the picture, so I'd say it is not worth the trouble. Just changing the compiler to supply rpath on binaries it builds might be safer approach. Various GCC builds on Solaris (OpenCSW, Sunfreeware, etc) are doing this for ages and mostly manage to pull things off. Third option is of course purging _all_ toolchain components out of the tree, which is such a fine bikeshed material that I am a bit scared to bring that up. --=20 Alexander Kabaev --Sig_/XFKAIIJj1u5yzyeZ2sdzvhl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPREHhQ6z1jMm+XZYRArmfAJ9eKupYTEZoAMKZkGApxcNIdM4fWgCg0tY3 sHg7MziXh9KrTiMYjutTfqY= =064P -----END PGP SIGNATURE----- --Sig_/XFKAIIJj1u5yzyeZ2sdzvhl--