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. > > [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. > 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. -- SteveReceived on Tue Feb 21 2012 - 22:52:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC