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: Tue, 9 Nov 1999 12:29:00 +1100
   From: Geoff Keating <geoffk@ozemail.com.au>

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

A hard error from which program?  The program linker or the dynamic
linker?

Are you suggesting that the program linker should reject an attempt to
use a symbol from a shared library which is only included indirectly?
That would break existing systems.  For example, on Solaris, the
shared X library includes other libraries.  If we rejected references
to shared libraries included indirectly, people would no longer be
able to simply link against -lX11.  This would also be incompatible
with the Solaris linker.

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

Yes, clearly.  I hope I haven't said anything to suggest otherwise.

Ian

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