<div dir="ltr">Ping? <div><br></div><div>If there's no further comments on this change, I'd like to commit it.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 2:48 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Joerg,<div><br></div><div>Any comments on this?</div></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 12:46 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Mon, Apr 7, 2014 at 12:27 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Mon, Apr 07, 2014 at 12:07:20PM -0700, Rui Ueyama wrote:<br>
> On Mon, Apr 7, 2014 at 3:32 AM, Joerg Sonnenberger<br>
> <<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>>wrote:<br>
><br>
> > On Sun, Apr 06, 2014 at 09:58:13PM -0700, Rui Ueyama wrote:<br>
> > > Currently LLD ignores undefined symbols found in DSOs when linking<br>
> > against<br>
> > > DSO files, if -shared flag is given. Internally, it's achieved by<br>
> > enabling<br>
> > > "useShlibUndefines" flag, which makes the file reader to ignore all<br>
> > undefined<br>
> > > symbols in DSO, so that Resolver don't see any undefined symbols when<br>
> > > handling DSO files.<br>
> ><br>
> > I don't think your patch fixes the real issue. The correct behavior<br>
> > is:<br>
> ><br>
> > (1) If the undefined symbol comes from an object file (or archive<br>
> > library), it is a true undefined symbol. In this case, the behavior<br>
> > depends on (a) -z defs (b) the output type. For shared libraries,<br>
> > undefined symbols are by default not fatal, for executables, they are.<br>
> ><br>
><br>
> That's I believe already implemetned correctly. Please take a look at<br>
> GnuLdDriver.cpp:295.<br>
><br>
> (2) Undefined symbols in shared libraries pulled in via -l are ignored.<br>
> ><br>
><br>
> By "ignored", I'd think you mean "undefined symbol from library is not<br>
> fatal", right?<br>
<br>
</div>No, I really meant ignored. The most you can or should do about them is<br>
check for consistency of the type. Otherwise they are completely<br>
irrelevant. Trying to resolve them is just going to waste time.</blockquote><div><br></div></div></div><div>That's different from my experiment. I reached the conclusion that GNU LD tries to resolve undefined symbols in library files by the following test case:<br>
<br></div><div><div> foo.c:</div><div> extern int bar();</div><div> int foo() { return bar(); }</div><div><br></div><div> bar.c:</div><div> int bar() { return 0; }</div><div><br></div><div> baz.c:</div><div> int baz() { return 0; }</div>
<div><br></div><div> usefoo.c:</div><div> extern int foo();</div><div> int usefoo() { return foo(); }</div><div><br></div><div> Makefile:</div><div> CFLAGS=-fPIC</div><div> all: libfoo.so libbar.so libbaz.so libusefoo.so</div>
<div> lib%.so: %.o</div><div> $(CC) -shared -o $@ $< -Wl,-rpath,`pwd`,--soname,$@</div><div> libusefoo.so: usefoo.o</div><div> $(CC) -shared -o $@ $< -Wl,-rpath,`pwd`,--soname,$@ -L`pwd` -lfoo -lbar -lbaz</div>
</div><div> </div><div>libfoo.so has undefined symbol "bar", but usefoo.o doesn't. If "bar" in libfoo.so is ignored, -lbar will not be linked to libusefoo.so, because at the time when linker processes "-lbar" there's no remaining undefined symbols. Reality is libusefoo.so has both "NEEDED libfoo.so" and "NEEDED libbar.so" (but not "NEEDED libbaz.so"). My interpretation of this result is that the linker tries to resolve undefined symbols in a library file.</div>
<div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
> (3) For ELF, shared libraries are processed recursively.<br>
><br>
> Are you talking about runtime behavior? Could you elaborate a bit?<br>
<br>
</div>No, link time behavior. GNU folks decided to break this in recent<br>
versions, but ELF has a recursive namespace and the linker should<br>
implement that. A simple case is linking against OpenSSL's libssl. That<br>
one is linked against libcrypto. For that reason, adding -lssl does<br>
add the symbols from libcrypto.so as well. Searching is controlled by<br>
the combination of libssl.so's rpath and the -rpath-link flags.<br>
<div><div><br>
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>