Home Original page

Bug in dynamic linker

Mark Kettenis kettenis@wins.uva.nl
Thu Jul 20 06:06:00 GMT 2000 
   Hi H.J.

   : 2000-07-18  H.J. Lu  <hjl@gnu.org>
   : 
   :       * bfd-in.h (bfd_elf_set_dt_needed_soname): New.
   :       * bfd-in2.h: Rebuild.
   : 
   :       * elf-bfd.h (elf_obj_tdata): Add dt_soname.
   :       (elf_dt_soname): New.
   : 
   :       * elf.c (bfd_elf_set_dt_needed_soname): New.
   : 
   :       * elflink.h (elf_link_add_object_symbols): Add the DT_NEEDED
   :       entry if the shared object loaded by DT_NEEDED is used to
   :       resolve the reference in a regular object.

   : 2000-07-18  H.J. Lu  <hjl@gnu.org>
   : 
   :       * emultempl/elf32.em (gld${EMULATION_NAME}_try_needed): Call
   :       bfd_elf_set_dt_needed_soname ().

   Approved.

IMHO, this patch needs some more discussion.  This isn't a simple
bugfix.  It changes the way the linker behaves from the user
standpoint considerably, since it will now silently add DT_NEEDED
entries for libraries that are not explicitly mentioned on the
command-line.  I also wonder if this patch could change the order of
the DT_NEEDED entries, e.g. can a DT_NEEDED generated by HJ's patch
come before a DT_NEEDED for a library mentioned on the command line?

Suppose I have an implementation of libfoo.so.1 that depends on
libbar.so.  I know link a program with libfoo.so.1.  Before HJ's patch
it would only get a DT_NEEDED entry for libfoo.so.1.  Now it will also
get one for libbar.so.

Now suppose that libfoo.so.1 is reimplemented such that it doesn't
depend on libbar.so.1, or even worse, depends on libbar.so.2 instead.
It is very likely that the program mentioned above won't work anymore
(either because libbar.so.1 is no longer present, or because there is
a conflict between libbar.so.1 and libbar.so.2).  Even if the program
itself doesn't use any symbols from libbar.so.1.

The current situation has its problems too (the "Bug in dynamic
linker" from the subject line[1]).  If your program does reference a
symbol from libbar.so.1, the link will succeed, but the dependency
will not be recorded as a DT_NEEDED (but version dependecies will be
recorded).  This can obvously result in obscure problems if the
implementation of libfoo.so.1 is changed as described above.

IMHO, the *correct* solution is implementing what the Solaris linker
does: refusing to link if a symbol in the program cannot be resolved
in one of the libraries mentioned on the command line (printing a
message if it can be found in one of those libraries dependencies to
help the user).

If the Solaris behaviour was implemented as the default behaviour, and
it has been verified that the library ordering issue doesn't occur, I
wouldn't have any objections against this patch.  However, right now
I'm not sure if it's a really good idea :-(.

Mark

[1] It isn't really a bug in the dynamic linker, but more a
case of the dynamic linker not spitting out a more appropriate error
message telling the user that it couldn't find the right version
information.
More information about the Binutils mailing list