<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 28, 2016 at 2:15 AM, Eugene Leviant <span dir="ltr"><<a href="mailto:evgeny.leviant@gmail.com" target="_blank">evgeny.leviant@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is how I stepped on a problem (simplified):<br>
<br>
clang a.out.o liba.so libb.so -o executable // got link error here<br>
when used lld, both gold and ld succeeded<br>
<br>
liba,so is built this way:<br>
<br>
clang a.o libb.so libstatic.a -o liba.so<br>
<br>
I wonder is this some sort of malformed or undocumented behavior of ld/gold?<br></blockquote><div><br></div><div>So,</div><div><br></div><div>  libb.so contains an undefined symbol <i>foo,</i></div><div>  libstatic.a contains a defined symbol <i>foo</i>, and</div><div>  no one except libstatic.a defines <i>foo</i></div><div> </div><div>then it will fail. But, I wonder why libb.so contains an undefined symbol <i>foo</i> in the first place, and why you passed an object file that must be linked as an archive member rather as a bare .o.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
2016-10-27 21:16 GMT+03:00 Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>>:<br>
> On Thu, Oct 27, 2016 at 11:08 AM, Rafael Espíndola<br>
> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>><br>
>> This is inconsistent with how lld looks at shared libraries.<br>
>><br>
>> We always use --allow-shlib-undefined, which basically means that we<br>
>> only look at share libraries to see what they provide and trust that<br>
>> they will have all their dependencies at run time.<br>
>><br>
>> If we absolutely must, we should probably just implement a<br>
>> --no-allow-shlib-undefined. But I would like a very strong<br>
>> justification before we do that.<br>
><br>
><br>
> I agreed. We intentionally do not try to resolve symbols in DSOs because it<br>
> doesn't make much sense. Such undefined symbols may be resolved not at<br>
> link-time but at runtime. In scanShlibUndefined, we do not resolves symbols,<br>
> but just mark symbols as ExportDynamic.<br>
><br>
>><br>
>><br>
>> Cheers,<br>
>> Rafael<br>
>><br>
>> On 27 October 2016 at 11:01, Eugene Leviant <<a href="mailto:evgeny.leviant@gmail.com">evgeny.leviant@gmail.com</a>><br>
>> wrote:<br>
>> > evgeny777 created this revision.<br>
>> > evgeny777 added reviewers: ruiu, rafael.<br>
>> > evgeny777 added subscribers: grimar, ikudrin, llvm-commits.<br>
>> > evgeny777 set the repository for this revision to rL LLVM.<br>
>> > evgeny777 added a project: lld.<br>
>> ><br>
>> > When linking DSO lld doesn't resolve symbols from input DSOs in case<br>
>> > those symbols are lazy. Below is an example:<br>
>> ><br>
>> > input.so - has undefined symbol 'print'<br>
>> > libprint.a - defines 'print'<br>
>> ><br>
>> > ld.lld -shared -o output.so input.so libprint.a<br>
>> ><br>
>> > Even though libprint.a has definition of 'print', output.so will have it<br>
>> > undefined.<br>
>> > Later when you link application with output.so, you'll also have to<br>
>> > provide libprint.a<br>
>> ><br>
>> > This patch fixes it.<br>
>> ><br>
>> ><br>
>> > Repository:<br>
>> >   rL LLVM<br>
>> ><br>
>> > <a href="https://reviews.llvm.org/D26033" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D26033</a><br>
>> ><br>
>> > Files:<br>
>> >   ELF/SymbolTable.cpp<br>
>> >   test/ELF/Inputs/shared4.s<br>
>> >   test/ELF/shared-lazy.s<br>
>> ><br>
>> ><br>
>> > Index: test/ELF/shared-lazy.s<br>
>> > ==============================<wbr>==============================<wbr>=======<br>
>> > --- test/ELF/shared-lazy.s<br>
>> > +++ test/ELF/shared-lazy.s<br>
>> > @@ -0,0 +1,10 @@<br>
>> > +# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o<br>
>> > +# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux<br>
>> > %p/Inputs/archive.s -o %t2.o<br>
>> > +# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux<br>
>> > %p/Inputs/shared4.s -o %t3.o<br>
>> > +# RUN: llvm-ar rcs %t2.a %t2.o<br>
>> > +# RUN: ld.lld -shared %t3.o -o %t3.so<br>
>> > +# RUN: ld.lld -shared %t.o %t2.a %t3.so -o %t.so<br>
>> > +# RUN: llvm-objdump -t %t.so | FileCheck --check-prefix=DEFINED %s<br>
>> > +<br>
>> > +# DEFINED: _start<br>
>> > +call _entry@plt<br>
>> > Index: test/ELF/Inputs/shared4.s<br>
>> > ==============================<wbr>==============================<wbr>=======<br>
>> > --- test/ELF/Inputs/shared4.s<br>
>> > +++ test/ELF/Inputs/shared4.s<br>
>> > @@ -0,0 +1,3 @@<br>
>> > +.globl _shared<br>
>> > +_shared:<br>
>> > +  call _start@plt<br>
>> > Index: ELF/SymbolTable.cpp<br>
>> > ==============================<wbr>==============================<wbr>=======<br>
>> > --- ELF/SymbolTable.cpp<br>
>> > +++ ELF/SymbolTable.cpp<br>
>> > @@ -549,9 +549,12 @@<br>
>> >  template <class ELFT> void SymbolTable<ELFT>::<wbr>scanShlibUndefined() {<br>
>> >    for (SharedFile<ELFT> *File : SharedFiles)<br>
>> >      for (StringRef U : File->getUndefinedSymbols())<br>
>> > -      if (SymbolBody *Sym = find(U))<br>
>> > +      if (SymbolBody *Sym = find(U)) {<br>
>> >          if (Sym->isDefined())<br>
>> >            Sym->symbol()->ExportDynamic = true;<br>
>> > +        else if (Sym->isLazy())<br>
>> > +          addUndefined(U);<br>
>> > +      }<br>
>> >  }<br>
>> ><br>
>> >  // This function processes --export-dynamic-symbol and --dynamic-list.<br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>