Re: Binutils linker bug?

[Mark Kettenis <kettenis at wins dot uva dot nl>]

[ For the people on binutils@sourceware: this is a followup on a
  binutils bug report that was sent to bug-utils@gnu.org.  I added
  binutils@sourceware to give it a bit more exposure. ]

jongk@cs.utwente.nl (Kars de Jong) writes:

> 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?  Should `ld' avoid recording the version dependencies
in this case?

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?

Mark