Re: rtld or lang/gcc cannot find libgcc_s.so.1

On Tue, 21 Feb 2012 11:42:59 -0800
Steve Kargl <sgk_at_troutmask.apl.washington.edu> 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:
> > > 
> > > troutmask:kargl[210] halfspace
> > > /lib/libgcc_s.so.1: version GCC_4.6.0 required
> > > by /home/kargl/bin/halfspace not foundtroutmask:kargl[211]
> > > 
> > > (Note, the annoying absense of a newline character after the error
> > > message, which is a completely different issue.)
> > > 
> > > I see this problem on both freebsd-i386 and freebsd-amd64.
> > > 
> > > troutmask:kargl[212] ldd ~/bin/halfspace
> > > /home/kargl/bin/halfspace:
> > >         liblapack.so.4 => /usr/local/lib/liblapack.so.4
> > > (0x2008c3000) libblas.so.2 => /usr/local/lib/libblas.so.2
> > > (0x201463000) libgfortran.so.3
> > > => /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5
> > > => /lib/libm.so.5 (0x201a70000) libgcc_s.so.1
> > > => /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0
> > > => /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7
> > > => /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] ldconfig -r
> > > | grep libgcc_s 29:-lgcc_s.1 => /lib/libgcc_s.so.1
> > >         723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
> > > 
> > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or 
> > > the lang/gcc port is no longer providing sufficient information
> > > for rtld to choose the correct library.
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > I highly suspect that you just happen to not need a symbol from the
> > newest namespace before.
> > 
> > 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.
> 
> Yes, /lib comes before /usr/local/lib/gcc46.  I suppose
> that this is a heads up for gerald_at_. lang/gcc is used by
> the ports collections to build a large number of other
> ports, so others are likely to hit this issue.
> 
> 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 
> 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 
> feasible.
> 

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.
-- 
Alexander Kabaev