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

[Joerg Sonnenberger via llvm-commits]

On Mon, Mar 21, 2016 at 08:05:20PM +0100, Rui Ueyama wrote:
> On Sun, Mar 20, 2016 at 1:52 AM, Joerg Sonnenberger via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> 
> > On Sat, Mar 19, 2016 at 10:16:31AM +0000, Rui Ueyama via llvm-commits
> > wrote:
> > > I agree with your argument that we should ignore that option. gold
> > > completely ignores that option, and the GNU ld's behavior to try to
> > > resolve undefined symbols in all shared object files at (static-)link
> > time seems broken to me.
> >
> > Actually, it is gold that is broken in this regard. Resolving undefined
> > symbols recursively is needed for correct ELF operation, it is just that
> > the GNU folks decided that once again that screwing with ELF is good.
> > The requirement to explicitly link against all libraries you import from
> > is stupid from the ELF perspective, both spec and implementation, as it
> > just slows things down. It also breaks valid use cases for hiding
> > implementation details...
> >
> 
> So we do not try to resolve any undefined symbols in any .so file, and
> therefore -rpath-link option does not make sense for us.

This is not about resolving undefined symbols in shared libraries, it is
about loading the right set of shared libraries in first place. If
libfoo links against libbar and the linker sees -lfoo, it should behave
as if -lbar was also used. There is some disagreement around binutils
folks insisting on spewing warnings about using symbols from libbar when
only linking against libfoo, but that's a different topic. It remains
that the namespace is defined as closure of the DT_NEEDED.

Joegr