<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 22, 2016 at 2:45 PM, Joerg Sonnenberger via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 21, 2016 at 08:05:20PM +0100, Rui Ueyama wrote:<br>
> On Sun, Mar 20, 2016 at 1:52 AM, Joerg Sonnenberger via llvm-commits <<br>
> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> > On Sat, Mar 19, 2016 at 10:16:31AM +0000, Rui Ueyama via llvm-commits<br>
> > wrote:<br>
> > > I agree with your argument that we should ignore that option. gold<br>
> > > completely ignores that option, and the GNU ld's behavior to try to<br>
> > > resolve undefined symbols in all shared object files at (static-)link<br>
> > time seems broken to me.<br>
> ><br>
> > Actually, it is gold that is broken in this regard. Resolving undefined<br>
> > symbols recursively is needed for correct ELF operation, it is just that<br>
> > the GNU folks decided that once again that screwing with ELF is good.<br>
> > The requirement to explicitly link against all libraries you import from<br>
> > is stupid from the ELF perspective, both spec and implementation, as it<br>
> > just slows things down. It also breaks valid use cases for hiding<br>
> > implementation details...<br>
> ><br>
><br>
> So we do not try to resolve any undefined symbols in any .so file, and<br>
> therefore -rpath-link option does not make sense for us.<br>
<br>
</span>This is not about resolving undefined symbols in shared libraries, it is<br>
about loading the right set of shared libraries in first place. If<br>
libfoo links against libbar and the linker sees -lfoo, it should behave<br>
as if -lbar was also used. There is some disagreement around binutils<br>
folks insisting on spewing warnings about using symbols from libbar when<br>
only linking against libfoo, but that's a different topic. It remains<br>
that the namespace is defined as closure of the DT_NEEDED.<br></blockquote><div><br></div><div>Where is that documented and who's depending on that? </div></div></div></div>