Hiyas,
I think I've discovered a bug in BinUtils 2.22. It's a bit of a nasty one to
specify exactly -- I'm not sure how much of the following criteria is necessary
to reproduce it.
1. I compiled binutils with sysroot support but without specifying a sysroot,
so ./configure --sysroot=. This is because I want to later modify the sysroot
at compile time using gcc --sysroot=whatever, but I hadn't got that far yet.
2. Glibc version 2.14.1 was compiled and installed with --prefix=/usr, which is
fairly standard, but the bug doesn't seem to show itself if it's compiled into
/. I have manually patched it to "fix" the known issue with RPC and a public
patch for some known CPUID issue. I don't believe these patches are necessary
to reproduce the suspected bug with binutils.
3. GCC version 4.6.3 is being used; it compiles sysroot without any extra
configure flags.
4. Most compilations using this toolchain work fine. However in the following
case: ... a) There is an application A, which I am attempting to compile, and
will be linked against a dynamic library B (because it's using functions in B),
and ... b) Dynamic library B is in /usr/lib, and ... c) Dynamic library B uses
functions in, and is linked against, dynamic library C, and ... d) Application
A does _not_ use functions in library C, and is _not_ linked against C, and ...
e) Library C is found in /lib,
In this case, ld complains that it cannot find library C. Using --verbose shows
that the SEARCH_DIR("=/lib") and SEARCH_DIR("=/usr/lib") are both present in
the build, however ld simply fails to find it and cannot open the file. It
therefore can't resolve all the functions and hence compilation fails.Libraries
C and B have already built fine -- and if there isn't this second level of
dependency, then the applications also compile absolutely fine, hence why I am
fairly sure this is a bug.
As stated before, sysroot is not actually being used, it's just being compiled
in. Without sysroot support, it works as intended.
I have found a work-around which allows compilation to succeed. That
work-around is by adding -rpath-link to the flags passed to ld. I've found the
best way of doing this is by using "CC=gcc -Wl,-rpath-link,/lib:/usr/lib"
[throughout - I've not investigated where it is or is not necessary]. Execution
of these files has never been a problem, so the ld-linux is resolving the
dependencies without issue -- it's just ld at compile time. This again adds
credence to it being a bug in ld, as rpath-link does not make any difference to
the paths that ld-linux looks to resolve dependencies..
Similarly forcing the -l<whaterver> (that is lowercase L) flag in the gcc
compilation, again fixes the problem - ld can find the library if specified on
the command line without a problem. It's just if it has to figure it out and
isn't informed via -rpath-link.
I hope this has explained the issue satisfactorily. I am able to reproduce the
fault if any further information is needed (although I'm now working around it
by not configuring with --sysroot, so it would be a bit of a pain -- however my
process is scripted and so it's perfectly possible).
Kindest Regards,
- Simon.
_______________________________________________
bug-binutils mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-binutils
