<div dir="ltr">I don't think there really ought to be an expectation that this works with an ar implementation which can't parse the LTO files.<div><br></div><div>The only way it works with GCC is that they ship /usr/lib/bfd-plugins/liblto_plugin.so which "claims" the LTO object files and tells ar about the symbol table.<div><br></div><div>Either users should be using llvm-ar, or LLVM should be shipping a gnu binutils plugin.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 10, 2020 at 1:34 PM Fangrui Song via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-04-08, Teresa Johnson wrote:<br>
>Adding a couple of lld folks.<br>
><br>
>I helped Shishir debug this, the link line looked like:<br>
>   /home/sjessu/build/bin/clang -O0 -flto -o jcstest jcstest.o<br>
> ./.libs/libjpeg.a<br>
>and the issue was that libjpeg.a was created with the system ar instead of<br>
>llvm-ar. It worked when recreating libjpeg.a with llvm-ar.<br>
><br>
>I noticed that the lld code has some special handling for the case<br>
>when there is a missing symbol table, which often happens with system ar<br>
>created archives containing bitcode. I noticed that the lld code will<br>
>sometimes emit an error, but actually contains a special hack to handle<br>
>archives containing *only* bitcode objects, so that they are handled<br>
>correctly even when there is no symbol table because it was created with<br>
>the system ar.<br>
<br>
<a href="https://reviews.llvm.org/D63781" rel="noreferrer" target="_blank">https://reviews.llvm.org/D63781</a> added the "archive has no index; run<br>
ranlib to add one" error.<br>
<br>
A clarification: the LinkerDriver::addFile code handles mix-and-match<br>
ELF object members and bitcode members. A LazyObjFile can be<br>
either an ELF object file or an LLVM bitcode file.<br>
<br>
>Unfortunately, in this case it neither gave an error nor did<br>
>the special handling, because libjpeg.a also contains some native objects<br>
>and thus had a non-zero symbol table. I created a version of libjpeg.a<br>
>using the system library and containing only the bitcode objects, and<br>
>confirmed it links fine with lld (the native objects weren't needed in this<br>
>case). BTW this is the code in ELF/Driver.cpp LinkerDriver::addFile.<br>
><br>
>Would it be possible to extend the hack in lld to handle cases like this<br>
>with some bitcode objects and some non-bitcode objects, so that the bitcode<br>
>objects are not simply ignored?<br>
><br>
>Thanks,<br>
>Teresa<br>
<br>
I guess what happened here is that the archive has an incomplete symbol table.<br>
nm -s (--print-armap) can print the symbol table.<br>
<br>
   % ar rc a.a a.bc a.o; nm -s a.a<br>
<br>
   Archive index:<br>
   _start in a.o<br>
   nm: a.bc: file format not recognized<br>
<br>
   a.o:<br>
   0000000000000000 T _start<br>
<br>
Currently lld trusts the archive symbol table. If the archive symbol table<br>
actually misses some entries (GNU ar does not add bitcode definitions to the<br>
symbol table), lld will not know that some lazy definitions are actually<br>
missing.<br>
<br>
It seems that if we have to make the GNU ar scenario work, lld has to distrust the archive symbol table when it contains bitcode files...<br>
To not pessimize the case with all bitcode members but no ELF object members, we need to refine the hack to "distrust" the archive symbol table<br>
if (the archive symbol table exists && an ELF object member exists && a bitcode member exists).<br>
<br>
Does this scheme sound good?<br>
<br>
>On Wed, Apr 8, 2020 at 10:25 AM Shishir V Jessu via llvm-dev <<br>
><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> To correct a typo: I am using both clang 6.0.0, and a local build of clang<br>
>> 10.0.0, and each result in the same error.<br>
>><br>
>> Best,<br>
>> Shishir Jessu<br>
>><br>
>> On Wed, Apr 8, 2020 at 12:22 PM Shishir V Jessu <<a href="mailto:shishir.jessu@utexas.edu" target="_blank">shishir.jessu@utexas.edu</a>><br>
>> wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> I have tried to build libjpeg-turbo<br>
>>> <<a href="https://github.com/libjpeg-turbo/libjpeg-turbo" rel="noreferrer" target="_blank">https://github.com/libjpeg-turbo/libjpeg-turbo</a>> with LTO in LLVM, using<br>
>>> both clangbut get many errors in lld that look like the following:<br>
>>><br>
>>> ld: error: undefined symbol: jpeg_std_error<br>
>>> >>> referenced by jcstest.c:76<br>
>>> >>>               lto.tmp:(main)<br>
>>><br>
>>> ld: error: undefined symbol: jpeg_CreateCompress<br>
>>> >>> referenced by jcstest.c:86<br>
>>> >>>               lto.tmp:(main)<br>
>>><br>
>>> ld: error: undefined symbol: jpeg_set_defaults<br>
>>> >>> referenced by jcstest.c:88<br>
>>> >>>               lto.tmp:(main)<br>
>>><br>
>>> ld: error: undefined symbol: jpeg_default_colorspace<br>
>>> >>> referenced by jcstest.c:90<br>
>>> >>>               lto.tmp:(main)<br>
>>> >>> referenced by jcstest.c:114<br>
>>> >>>               lto.tmp:(main)<br>
>>><br>
>>> This only occurs when compiling with the -flto flag. Has anyone been able<br>
>>> to build libjpeg-turbo with LTO? Are there any modifications I need to make<br>
>>> to the makefile or other configuration in order to do so? Thanks for your<br>
>>> help!<br>
>>><br>
>>> Best,<br>
>>> Shishir Jessu<br>
>>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
><br>
><br>
>-- <br>
>Teresa Johnson |  Software Engineer |  <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>