Re: Binutils linker bug?

[Roland McGrath <roland at frob dot com>]

> As I recall, I put in the indirect referencing stuff at the request of
> Roland McGrath for glibc.  It's been in there since 1995, and I'm a
> bit reluctant to take it out now.

I can believe I requested this at that time.  But now I am inclined to
think the behavior Geoff wants does perhaps make the most sense.  It's also
a bit unpleasant to be incompatible with other canonical ELF linkers on
something like this.

This affects the Hurd, where libc depends on some other shared objects to
provide symbols called by libc itself.  What's affected are programs that
use some of these symbols from the secondary libraries directly.  Currently
a program linking against just libc can refer to the symbols defined in
libc's dependency libraries; it links ok, and gets a DT_NEEDED only for
libc and not for the indirect dependency's soname.  A change to the Solaris
behavior would require these programs to add the appropriate libraries to
their link lines.  Given the exact details of what these libraries are in
the Hurd, I don't think it would be a problem for us to adapt to this by
changing the affected programs' makefiles.

> Let's go back to why it's a bad idea.  You're right that it can permit
> a link to succeed which can then break if a shared library is changed.
> But, after all, that is always true: any link can break if a shared
> library is changed.  Why is this different?

The rationale I see is that one might reasonably consider a given shared
object's set of dependency shared objects and the symbols they provide to
be an implementation detail of that shared object, rather than contributing
to that shared object's ABI.  It would then be reasonable to want to
replace that shared object with a new one that has a compatible ABI
(defined as just the symbols defined in that shared object itself), but has
a different implementation that includes a different set of dependency
shared objects.

The benefit of the Solaris behavior is that it allows a shared object to
use other shared objects as an incidental implementation detail, and later
be replaced with a shared object using a different set of other objects
(with different symbols) for its implementation, without breaking the ABI
compatibility that could have reasonably been expected by anyone who
succeeded in linking against the old object.

Conversely, the benefit of the current GNU behavior is that it permits a
shared object to use other shared objects as an incidental implementation
detail, including letting those other objects define some of the symbols of
"its" ABI.  This is something that I would like to be able to exploit as
well.  However, it now occurs to me that DT_AUXILIARY does exactly this
just fine and I don't see why I wouldn't be happy using that for whatever
new arrangements come up in the future.  It may well be that my original
thinking on this and my request to you for this behavior in GNU ld predate
Sun's invention of the DT_AUXILIARY extension (or at least my knowledge of it).

So in conclusion I think that GNU ld should indeed change to match the
Solaris behavior.  But it is an incompatible change that at least Hurd code
will need to adapt to, so it should be well noted and perhaps wait a while.
(I can probably just change Hurd's libc to use DT_AUXILIARY for now and not
require any other immediate adaptations to work with the new ld behavior.)