Does ld need to search for DT_NEEDED objects?
Ian Lance Taylor
iant@google.com
Wed Nov 8 15:51:00 GMT 2006
In ld/emultempl/elf32.em we have some complex code which tries to
emulate the algorithm used by the dynamic linker to find shared
objects. This includes ugly cases like GNU/Linux special case code to
ignore shared objects with the correct name but which use the wrong
version of libc, and the whole concept of --rpath-link. And the
algorithm in ld does not match the one used by ld.so anyhow, as it
ignores ${ORIGIN} and the use of hardware capabilities.
While I don't remember all the history, I think this approach stemmed
from a poor decision on my part back in 1995:
Mon Feb 6 14:25:24 1995 Ian Lance Taylor <ian@cygnus.com>
* libelf.h (struct elf_link_hash_table): Add saw_needed field.
* elfcode.h (elf_link_add_object_symbols): Set saw_needed if
DT_NEEDED seen in .dynamic section.
(elf_link_output_extsym): Warn if an undefined symbol is
only referenced from a dynamic object, and not making a shared
object, and saw_needed is false.
* elf.c (_bfd_elf_link_hash_table_init): Initialize saw_needed.
I decided to add a warning when ld sees a dynamic object with a symbol
which does not appear to be defined anywhere. Or maybe somebody else
suggested it, I don't remember. Either way, the idea of this warning
snowballed into the code we have now.
I now think this is all a bad idea. It's too hard and complicated for
ld to try to emulate ld.so when they don't share any code. Users are
routinely confused by the whole --rpath-link notion. The only benefit
from the search is a warning that a symbol may be undefined. The
warning is inherently inaccurate since it can only test the shared
objects available at link time, which may of course be completely
different at runtime. I suspect that significantly more users are
confused by these warnings than are actually helped by them.
There is an accurate way to get these warnings, which is to run ldd -r
EXECUTABLE. I suspect that the people who are helped by these
warnings (i.e., have an executable about which ld would warn but which
does not fail at runtime) are sophisticated enough to be able to run
this test.
I would like to hear from anybody who thinks that it is a good idea to
do this searching in ld. Thanks.
Ian
More information about the Binutils
mailing list