Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Sat, 25 Feb 2012 10:41:59 -0800 Tim Kientzle wrote: > > On Feb 23, 2012, at 9:16 AM, Alexander Kabaev wrote: > > > On Tue, 21 Feb 2012 21:11:13 -0800 > > Tim Kientzle wrote: > > > >> > >> If I understand correctly, the libgcc in base is pretty stripped > >> down compared to "regular" libgcc, because most of that > >> stuff is in our libc instead. > >> > > > > You understand it a bit wrong, but your conclusions are correct. > > libgcc in base is not stripped in any way and is supposed to be > > identical to one coming from upstream. > > So where is __umodsi3 supposed to be defined for ARM? > > In FreeBSD, libgcc refers to it but does not define it. > It's defined in libc. > > I stumbled across this trying to link some freestanding > ARM code using the native cross-compilers. The link > failed if I used -nostdlib because of a handful of symbols > such as this. > > Tim I do not know how embedded architectures split it these days and I am not even sure if we have an official ARM port in FSF GCC, but in general these belong in static portion of libgcc.a. If you'd look at bmake glue in gnu/lib/libgcc, you will see that building of __umodsi was there but was disabled by our arm folks presumably because of switch to our own complete softfloat implementation that happens to be in libc. They probably should not have disabled integer math stuff along with libgcc's incomplete floating point implementation, but I guess they had their reasons. Non-embedded architectures do not do that and for amd64/i386 each GCC import since 3. ensured that libgcc_s.so matched one produced by upstream symbol-by-symbol. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Feb 23, 2012, at 9:16 AM, Alexander Kabaev wrote: > On Tue, 21 Feb 2012 21:11:13 -0800 > Tim Kientzle wrote: > >> >> If I understand correctly, the libgcc in base is pretty stripped >> down compared to "regular" libgcc, because most of that >> stuff is in our libc instead. >> > > You understand it a bit wrong, but your conclusions are correct. libgcc > in base is not stripped in any way and is supposed to be identical to > one coming from upstream. So where is __umodsi3 supposed to be defined for ARM? In FreeBSD, libgcc refers to it but does not define it. It's defined in libc. I stumbled across this trying to link some freestanding ARM code using the native cross-compilers. The link failed if I used -nostdlib because of a handful of symbols such as this. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 21:11:13 -0800 Tim Kientzle wrote: > > On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: > > > On Tue, 21 Feb 2012, Steve Kargl wrote: > > > >> 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? > > Why not? Would it cause problems? > > Is libgcc from GCC 4.6 incompatible with /lib/libgcc? > > If I understand correctly, the libgcc in base is pretty stripped > down compared to "regular" libgcc, because most of that > stuff is in our libc instead. So if there were compatibility > problems, I'd expect those to show up when GCC 4.6 linked > programs against /usr/local/.../libgcc and /lib/libc. > You understand it a bit wrong, but your conclusions are correct. libgcc in base is not stripped in any way and is supposed to be identical to one coming from upstream. As long as upstream maintains backward compatibility, their library should be a perfect replacement for ours. There was a time period while FreeBSD used dynamic unwind into search using dl_iterate_phdr while upstream GCCs didn't, but that was fixed by GCC folks switching GCC to use dl_iterate_phdr on Linux and FreeBSD by default quite while ago. I am not aware of any other incompatibilities at this time. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On 2012-Feb-21 17:00:53 -0500, Diane Bruce wrote: >Or is this another problem? -rpath is added in /usr/ports/Mk This may help for applications built wihin the ports framework but doesn't help if you want to use gcc46 as a general purpose compiler. On 2012-Feb-21 23:03:27 -0500, Benjamin Kaduk wrote: >How would things break if we made everything in the base system specify >-rpath of /lib and /usr/lib as appropriate, and then put the ports >versions first in the default search path? I have a nasty feeling this would break i386 emulation on amd64 - if the i386 executable has an embedded rpath pointing to /lib, it will fail to find the shared libraries in /lib32. On 2012-Feb-21 20:16:12 -0500, Alexander Kabaev wrote: >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. I agree this is the way to go. I tried suggesting this in ports/142226 but it got closed without actually fixing the problem. (IMO, the whole -rpath approach is backwards - in virtually all cases, if you link against a library at a specific path, you are going want to run against that library as well so the default should be to look there, with something like -rpath only used in the few cases where that isn't correct). >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. One of the big advantages of FreeBSD is that it can recompile itself. Having to install ports to do this would be a massive step backwards and wouldn't actually solve the underlying problem unless you were restricted to having no more than one installed toolchain (which has other problems). -- Peter Jeremy pgpoXO8nfo0ZF.pgp Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: > On Tue, 21 Feb 2012, Steve Kargl wrote: > >> 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? Why not? Would it cause problems? Is libgcc from GCC 4.6 incompatible with /lib/libgcc? If I understand correctly, the libgcc in base is pretty stripped down compared to "regular" libgcc, because most of that stuff is in our libc instead. So if there were compatibility problems, I'd expect those to show up when GCC 4.6 linked programs against /usr/local/.../libgcc and /lib/libc. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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@. 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.
I think there is perhaps a little more to this issue of multiple
(incompatible) copies of a library with the same name being installed,
e.g. libcom_err in /usr/lib/libcom_err.so and
/usr/local/lib/libcom_err.so. An application using the library must
#include to get the library prototypes, but the preprocessor
puts the standard include search path /usr/include at the end of the
search list, even if it is specified explicitly on the command line,
unless -nostdinc is passed. So this will prefer the header from ports in
the absence of evil trickery.
I was pounding my head against this a couple years ago, so my memory is
not quite fresh, but I think that I could convince the compile-time link
step to use either version of the library with the appropriate ordering of
-L arguments (but I am in trouble if I want libkrb5.so from ports and
libcom_err.so from base!).
In any case, the dynamic linker will search the default search path
*first*, preferring the copy of the library from the base system. After
pounding my head against the issue for a while I concluded that I had no
option other than to use -rpath (but alas I ran out of time for that
particular project and never finished).
It is definitely an ugly situation and I have no good answers. It would
be nice to not have to specify every detail of what should be happening,
though.
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.
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.
4) Suggestions from people that are brighter than I.
How would things break if we made everything in the base system specify
-rpath of /lib and /usr/lib as appropriate, and then put the ports
versions first in the default search path?
-Ben Kaduk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 15:52:08 -0800
Steve Kargl 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@. 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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 11:42:59 -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: > > > > > > 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 (0x201a7) 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@. 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 signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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@. 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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@. 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.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On 2/21/2012 23:32, 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@. 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. Make sure it's your binary pulling in libgcc_s. I just went through a few iterations of recompiling mplayer with different *FLAGS and each time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and saw libschroedinger was the one actually pulling it in. Recompiled libschroedinger with gcc46 by putting USE_GCC=46 in the Makefile and sure enough: % ldd `which mplayer`|grep gcc libgcc_s.so.1 => /usr/local/lib/gcc46/libgcc_s.so.1 (0x29625000) In short, bsd.gcc.mk is doing the right thing, but dependencies may screw things up. -- Mel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Wed, Feb 22, 2012 at 12:22:50AM +0100, Mel Flynn wrote: > On 2/21/2012 23:32, 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@. 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. > > Make sure it's your binary pulling in libgcc_s. I just went through a > few iterations of recompiling mplayer with different *FLAGS and each > time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and > saw libschroedinger was the one actually pulling it in. > I already did the ldd song and dance. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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@. 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.
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.
4) Suggestions from people that are brighter than I.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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@. 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 ? man ld -rpath dir Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link; see the description of the -rpath-link option. If -rpath is not used when linking an ELF executable, the contents of the environment variable "LD_RUN_PATH" will be used if it is defined. Or is this another problem? -rpath is added in /usr/ports/Mk > However, at runtime, it links against the system libstdc++: I ran into this with two of my own ports. -rpath needed to be passed to ld. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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@. lang/gcc is used by > the ports collections to build a large number of other > ports, so others are likely to hit this issue. The same applies to libstdc++.so.6, if you compile any C++ program with e.g. g++46. During the link stage, g++ sets the library path so that /usr/local/lib/gcc46/libstdc++.so is linked against the program: ... COMPILER_PATH=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/bin/ LIBRARY_PATH=/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'cpptest' '-v' '-shared-libgcc' '-mtune=generic' '-march=i486' /usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/collect2 --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o cpptest /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtbegin.o -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3 -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../.. cpptest.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtend.o /usr/lib/crtn.o However, at runtime, it links against the system libstdc++: $ ldd ./cpptest ./cpptest: libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28098000) libm.so.5 => /lib/libm.so.5 (0x28171000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2818d000) libc.so.7 => /lib/libc.so.7 (0x28198000) Some (simple) C++ programs handle this just fine, others die horribly... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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: > > > > > > 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 (0x201a7) > > > 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@. 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. 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. pgpxjeQZdJNRo.pgp Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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 (0x201a7) > > 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@. 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. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > Sorry about the cross post, but I can't tell if this > a -current issue of a -ports issue. Unfortunately, > I updated my freebsd 10.0 systems and the lang/gcc > port during the same timeframe. > > I have compiled my math library and several programs > with gfortran, which is installed by lang/gcc (pkg_info > shows gcc-4.6.2_1). When I try running the program > I get > > 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 (0x201a7) > 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. pgpXcBSnHGVyN.pgp Description: PGP signature
rtld or lang/gcc cannot find libgcc_s.so.1
Sorry about the cross post, but I can't tell if this a -current issue of a -ports issue. Unfortunately, I updated my freebsd 10.0 systems and the lang/gcc port during the same timeframe. I have compiled my math library and several programs with gfortran, which is installed by lang/gcc (pkg_info shows gcc-4.6.2_1). When I try running the program I get 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 (0x201a7) 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. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
