This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Binutils linker bug?


> Date: 8 Nov 1999 16:30:47 -0500
> From: Ian Lance Taylor <ian@zembu.com>
> CC: jongk@cs.utwente.nl, binutils@sourceware.cygnus.com

> When considering whether ld should issue a warning, we should ask what
> the dynamic linker will do.  ld should not issue a warning if the
> dynamic linker will handle things correctly.  ld should issue a
> warning if the dynamic linker will not handle things correctly.
> 
> To put it another way, I don't agree that the testcase is broken.
> There is no requirement that he explicitly link against libpthread.so.
> I agree that it would be more normal to do so.

I'd disagree with this.  Consider the situation when we have the
following:

a shared library, libsomething.so, linked against libpthread.so.0.9.0
a system with libpthread.so.0.9.1 in /usr/lib, which might be
symlinked as version 0.9.0 or might be different.

and we are building a main program, which uses libsomething, and which
calls routines that are in libpthread but does not link against it.

Which version of the routines should we be using?

IMHO, this should be a hard error, "symbol not found".

>    However, if the program references `write' instead of `pthread_self'
>    things are a little different.  I think the desired behaviour here is
>    to record that the program needs the appropriate version of `write'
>    from libc.so instead of libpthread.so (which gets sucked in via an other
>    library we link against).  Is this failing because `write' is weak in
>    libc.so and isn't in libpthread.so?  Or would it be a problem anyhow,
>    that is, even when `write' is weak in libpthread.so too?
> 
> Again, the question to ask is what the dynamic linker will do.  The
> behaviour of ld should be guided by that.  If the dynamic linker will
> use `write' from libpthread.so, then I think ld should as well.

Consider a shared library that uses libpthread.so as part of its
internal processing, and a main program that is not threaded and does
not use libpthread, but is linked against this shared library.

Now consider what happens when the shared library is modified, so that
it no longer uses libpthread.

Shouldn't the main program still work?

-- 
Geoffrey Keating <geoffk@cygnus.com>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]