Re: Bug in dynamic linker

["H . J . Lu" <hjl at lucon dot 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.

> 
> 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

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

> 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 :-(.
> 

Send me a testase if you still believe you are right.


H.J.