Suspected bug in binutils / ld (using ver 2.22).

[Simon B]

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.