Re: Binutils linker bug?

[Ian Lance Taylor <ian at zembu dot com>]

   From: Mark Kettenis <kettenis@wins.uva.nl>
   Date: 08 Nov 1999 22:23:22 +0100

   > Note that this testcase doesn't entirely represent the situation: in the
   > cases I ran into the bug (JDK 1.2.1 and ToolTalk version 1.3) the main
   > program that used the lib didn't call any pthread functions itself!
   > But I couldn't get the testcase to pull in pthread symbols without adding the
   > pthread_self() call to the main program.

   I think you get the same result if you use write() instead of
   pthread_self() in your main program.  libpthread overrides several
   system calls that can block for a long time to make them cancellation
   points.  In this context the fact that `write' is weak in libc.so but
   an ordinary symbol in libpthread.so.

   To me, this indicates that Kars's problems might be more complicated
   than they would seem at first sight.

   I think that everybody agrees that the testcase Kars gave (with main
   explicitly calling pthread_self()) is broken in the sense that he
   should link his program explicitly against libpthread.so.  Would it be
   a good idea to let `ld' issue a warning if he doesn't link against
   libpthread.so?

I don't think so.  We added recursive lookup of libraries which are
NEEDED by other libraries included in the link specifically to avoid
issuing warnings.

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.

   Should `ld' avoid recording the version dependencies
   in this case?

I don't think this would be correct.  After all, if version
dependencies mean anything at all, you have to record them when a
program calls a versioned symbol in a shared library.  That is what is
happening here: a program is calling the versioned symbol
pthread_self.  If ld doesn't store the version dependencies, what are
we saying?  That the versions don't matter?  But then why should we
bother with them at all?

   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.

Ian