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

From: Daniel Eischen <deischen_at_freebsd.org>
Date: Tue, 21 Feb 2012 18:39:36 -0500 (EST)
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/ ??

> 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?

> 4) Suggestions from people that are brighter than I.

[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?

   o Change affected ports to use -rpath when building?

-- 
DE
Received on Tue Feb 21 2012 - 22:56:16 UTC

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