[PATCH] D18269: [ELF] - -rpath-link "implemented"

[Joerg Sonnenberger via llvm-commits]

On Tue, Mar 22, 2016 at 04:03:42PM -0400, Rafael Espíndola wrote:
> >>
> >> Where is that documented and who's depending on that?
> >
> > "Shared Object Dependencies" in the original ELF specification.
> 
> http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies
> 
> That one?

Good enough, yes.

> >The
> > depth-first search only really matters for copy relocations when you
> > have more than one definition, which is likely a bug in first place. But
> > scanning all nodes in the tree before throwing an undefined error
> > matters quite a bit. A lot of software depends a lot and has to be
> > "fixed" when dealing with one of the (broken, IMO) newer versions of
> > binutils.
> 
> I have seen the argument before of backward compatibility, but never
> that it was actually better semantics. Can you expand a bit on why you
> prefer it?
> 
> The arguments I have seen against it is that foo.so using bar.so is an
> implementation detail. If an image format uses zlib for compression,
> it should be free to one day change that. If any client of that .so
> can for ever assume that zlib is used then a .so can never drop a
> dependency.

Changing the semantics would make sense if it actually helped anything.
A module system and integrating that with the way relocations are
specified could do that, so that you can bind external symbols to a
given DSO. But the binutils change never did that. The result is that
they just forced a blown up DT_NEEDED list. The argument with the
implementation detail works both ways. I can move part of the
implementation of foo.so into bar.so without breaking ABI compatibility.
Newer binutils break that.

The justification given was always to record the precise DT_NEEDED list,
in the sense that for every undefined symbol, the defining DSO is on the
DT_NEEDED list. I don't agree that it necessarily makes binary
package management easier as ABI consistency checking is much more
involved than just comparing DT_NEEDED lists. But even if you follow
that reasoning, the result could be obtained without forcing everyone to
list all the libraries needlessly on the command line. In short, it just screwed
a lot of existing Makefiles without really adding an advantage, which is
pretty stupid as default behavior.

Joerg