Before https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff;f=ld/emultempl/elf32.em;h=83a554fa7495e169e02f9157ac7bffc1609282b7;hp=ea7bad08e7ef189bfb2a66d9b7d65ebe69bce4f6;hb=4706eab946cabc77df441377e1e7ee7767197076;hpb=0b000dbb4929f9478633f3bf4a2a84c989befecb ie: +2013-04-26 Alan Modra <amodra@gmail.com> + + * emultempl/elf32.em (gld${EMULATION_NAME}_after_open): Test + unresolved_syms_in_shared_libs rather than !executable to + determine whether to load DT_NEEDED libraries. ... we could check whether our shared libraries had accidentally acquired a new dependency on eg strcpy like this: martind@swiftboat:~/tmp/D110979$ cat use-strcpy.c #include <string.h> void* use = &strcpy; martind@swiftboat:~/tmp/D110979$ gcc -shared use-strcpy.c -o use-strcpy.so martind@swiftboat:~/tmp/D110979$ readelf --dynamic use-strcpy.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] martind@swiftboat:~/tmp/D110979$ Before that change, we'd see: martind@swiftboat:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared use-strcpy.so --no-allow-shlib-undefined use-strcpy.so: undefined reference to `strcpy@GLIBC_2.2.5' martind@swiftboat:~/tmp/D110979$ ... unless we specified the library explicitly, along with everything it depends on: martind@swiftboat:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared use-strcpy.so /lib/x86_64-linux-gnu/libc-2.13.so /lib64/ld-linux-x86-64.so.2 --no-allow-shlib-undefined martind@swiftboat:~/tmp/D110979$ With that change, however, the link silently succeeds: martind@swiftboat:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared use-strcpy.so --no-allow-shlib-undefined martind@swiftboat:~/tmp/D110979$ ... providing that all the dependencies can be satisfied on the host. I wonder if that was deliberate. I foresee a "yes" and a "closed invalid" but I thought it worth noting, where Google will find it, that the semantics of the --no-allow-shlib-undefined switch was changed.
The patch was a deliberate change, with the rationale being that whether or not a shared library was loaded to satisfy the DT_NEEDED entry of some other library, should not depend on what sort of output ld is generating. (At least, the underlying options that control loading of shared libraries shouldn't have their behaviour modified if an option is explicitly given. Having different default options depending on output is a different story.) As a side-effect, the change made ld --no-allow-shlib-undefined ld -shared --no-allow-shlib-undefined ld -pie --no-allow-shlib-undefined all behave the same with respect to reporting undefined symbol errors in shared libraries. The option --no-allow-shlib-undefined is about input shared libraries, just as --no-undefined is about input regular object files, so I think being consistent here is also good. However, what I did in making --allow-shlib-undefined/--no-allow-shlib-undefined affect loading of DT_NEEDED shared libraries is quite suspect. It certainly would be more logical to make --copy-dt-needed-entries/--no-copy-dt-needed-entries the only controlling option over loading DT_NEEDED shared libraries. So I'm not going to mark the bug invalid as you feared, but it may end up as WONTFIX if the fix is too disruptive..
Different DT_NEEDED behavior related to --allow-shlib-undefined is probably not good. See bug 26551 for an example.