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

[Rui Ueyama via llvm-commits]

On Tue, Mar 22, 2016 at 2:45 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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.
>

Where is that documented and who's depending on that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160322/4944a2ee/attachment.html>