Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Feb 2012 22:09:12 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc:        freebsd-current@freebsd.org, freebsd-ports@freebsd.org
Subject:   Re: rtld or lang/gcc cannot find libgcc_s.so.1
Message-ID:  <20120221200912.GN55074@deviant.kiev.zoral.com.ua>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

--l3ej7W/Jb2pB3qL2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 21, 2012 at 11:42:59AM -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/hal=
fspace
> > >  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 (0x2008c300=
0)
> > >         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.
No, it is not feasible. The version check that tripped is there to check
consistency, and not to start loading. In fact, it is too late to
load other library (with the same name). The configuration needs to
be fixed, and not the rtld.

--l3ej7W/Jb2pB3qL2
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAk9D+egACgkQC3+MBN1Mb4hsgwCgkwfC8JKfoSZUDyNZ0TSqJE0u
zmsAoKBCBRysiqc4ItjRIjIHtkvh2XoA
=IOY0
-----END PGP SIGNATURE-----

--l3ej7W/Jb2pB3qL2--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120221200912.GN55074>