This is the mail archive of the
mailing list for the binutils project.
Re: Bug in dynamic linker
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: Bug in dynamic linker
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Thu, 20 Jul 2000 09:04:11 -0700
- Cc: nickc at cygnus dot com, binutils at sourceware dot cygnus dot com
- References: <200007201306.PAA10937@debye.wins.uva.nl>
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). 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
> 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.