From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org
Cc: nickc@cygnus.com, binutils@sourceware.cygnus.com
Subject: Re: Bug in dynamic linker
Date: Thu, 20 Jul 2000 10:11:00 -0000
Message-id: <200007201710.e6KHAmL09137@delius.kettenis.local>
References: <200007201306.PAA10937@debye.wins.uva.nl> <20000720090411.A5750@lucon.org>
X-SW-Source: 2000-07/msg00312.html

   Date: Thu, 20 Jul 2000 09:04:11 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Thu, Jul 20, 2000 at 03:06:29PM +0200, Mark Kettenis wrote:
   > 
   > 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.

   Are you just guessing or do you have a testcase? If you have a
   testcase, please send it to me. I have verified your case won't
   happen unless your program uses libbar.so. Try it yourself. If ld
   adds libbar.so to DT_NEEDED, it is a bug and you should report
   it to me.

Admittedly the problem scenario is a little more complicated than
what I wrote before, and perhaps Linux-specific, but here it is:

Suppose you have a libfoo that is linked agains libpthread.  Suppose
you have a program foo that references close, and is linked with
libfoo.  Remember that close is a weak symbol in libc and a normal
symbol in libpthread.  That means that by walking the DT_NEEDED chain,
ld will prefer the definition in libpthread.  I believe that with your
patch foo will get a DT_NEEDED for libpthread.  The reason I believe
this is true, is that right now ld records the version information for
close in libpthread.  This was the exact scenario causing the
origional "bug".

So you see that there are cases where a program doesn't explicitly
reference a symbol in a particular library, it will nevertheless get
a DT_NEEDED for that library.

   > 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

   The Solaris behavior won't some runtime symbol version mismatch. We
   do.

Sorry, I cannot parse that sentence.  What do you mean?

Mark