On Tue, 21 Feb 2012 11:42:59 -0800 Steve Kargl <s...@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@. 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
