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

From: Alexander Kabaev <kabaev_at_gmail.com>
Date: Tue, 21 Feb 2012 20:07:31 -0500
On Tue, 21 Feb 2012 15:52:08 -0800
Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:

> On Tue, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
> > On Tue, 21 Feb 2012, Steve Kargl wrote:
> > 
> > >On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
> > >>On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
> > >>>On 2012-02-21 20:42, Steve Kargl wrote:
> > >>>...
> > >>>>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.
> > >>
> > >>Does -rpath not help ?
> > >
> > >I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
> > >to my various projects.  I can also build with -static to avoid
> > >rtld.  One can also use LD_LIBRARY_PATH.
> > >
> > >The issue seems to be that lang/gcc will be installed after
> > >system start, and 'ldconfig -m' appends new shared libraries
> > >to the hints file.  This means that libraries with the same
> > >name but different locations will be found via the order of the
> > >search path in the hints file, and one gets the wrong library.
> > >That is, with the following
> > >
> > >troutmask:root[256] 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
> > >
> > >29 will be found before 723.  While I can work around the
> > >issue, lang/gcc is used by a rather large boatload of ports
> > >during the building process and I suspect that a large
> > >number of FreeBSD users use lang/gcc for their everyday
> > >compiler.  The question is how do we, the FreeBSD project,
> > >deal with this issue, so that the general user base does not
> > >get hit with it.
> > >
> > >There are a few solutions:
> > >1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
> > >  be scanned before /lib and /usr/lib.
> > >2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
> > >  for /lib and /usr/lib.
> > 
> > s/for/before/ ??
> 
> yes.  sorry about the typo.
> 
> > 
> > >3) Add a new option to ldconfig to prepend new libraries to
> > >  the hints files and fix the ports to use this option instead
> > >  of -m.
> > 
> > You don't want system binaries that want /lib/libgcc_s.so.1
> > to use /usr/local/lib/gccXX/libgcc_s.so.1, though.  Wouldn't
> > your option 3 do that?
> 
> Well, yes, I suppose that could be a problem. :)
> 
> > >4) Suggestions from people that are brighter than I.
> > 

Well, newer libgcc_s.so.1 should be backward compatible with older
ones, so that should not be the problem and if there are any, we need
to find and fix them.

> > [Not brighter than you, but]
> > 
> >   o For our system libgcc, use libcc_s.so.1 (or some other
> >     name) instead of libgcc_s.so.1?
> 
> Interesting idea.  Perhaps, the port should install libgcc46_s.so.1,
> and binaries installed by lang/gcc updated to use this library.
> 

'shared' portion of libgcc was meant to _be_ shared specifically and in
general having two copies of unwind code and two copied of unwind
frames handling logic is probably not what GCC is expecting.

> >   o Change affected ports to use -rpath when building?
> 
> I started to look into this option, but it quickly becomes
> apparent that some (evil) configure hackery may be needed.
>

It can be done in GCC specs for all the programs that use CC driver to
to the linking. Of course, all direct LD invocations will need to be
found and fixed as well, but those were always fragile anyway.


> -- 
> Steve
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"


-- 
Alexander Kabaev

Received on Wed Feb 22 2012 - 00:38:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC