<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 11:26 AM, Ed Maste via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 15 March 2017 at 16:34, Carsten Mattner <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:<br>
><br>
> If FreeBSD's libtool is patched to be aware of the base ld=lld,<br>
> would this still be true?<br>
<br>
</span>Yes, for the same reason Joerg points out in another reply in this<br>
thread - some software packages are going to include in their<br>
configure scripts parts of whatever libtool version existed on the<br>
machine used by a developer to produce a release.<br></blockquote><div><br></div><div><br></div><div>It looks like we've picked up Phoronix's attention:</div><div><a href="http://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=3">http://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=3</a><br></div><div>Note that they did this test in the most brutal possible way (replacing /usr/bin/ld with LLD).</div><div><br></div><div>It seems that they found that a few packages failed to build with LLD.</div><div><br></div><div>I tried reproducing the libjpeg-turbo one and it seems likely to be due to differences in configure. This is the diff: <a href="https://reviews.llvm.org/P7977">https://reviews.llvm.org/P7977</a></div><div><br></div><div>I can't repro the libjpeg-turbo failure configuring with a plain -fuse-ld=lld (using clang as CC, and with /usr/bin/ld as ld.bfd). It seems that the configure scripts actually call directly into /usr/bin/ld for this check or something similarly nasty (which is pretty suspect, since it defeats whatever linker feature is being tested when it invokes the linker "for real" through CC `).</div><div><br></div><div>Adding "not GNU" into the version string seems to allow libjpeg-turbo to build (though it still detects shared libraries aren't available, and adding `: supported targets: elf` in --help seems to get shared libraries back). With those two hacks (patch attached), I see the following configure diff which seems benign: <a href="https://reviews.llvm.org/P7978">https://reviews.llvm.org/P7978</a></div><div>See the thread "lld status on the freebsd ports" where Rafael shared his findings from the freebsd ports, inclusing these hacks.</div><div><br></div><div>I think we should seriously consider adding these hacks (possibly in a way that more clearly highlights to users why we had to put them in, such as "the following lines are for libtool < vX.Y:"). Realistically, even if we land a fix in upstream libtool today, we are unlikely to be able to really rely on that in the wild for perhaps 5 years. I don't think our users should have to wait that long for LLD to "Just Work" for them. We want LLD to have as little "fine print" as possible.</div><div><br></div><div><br></div><div>It looks like "stockfish" and "TTSIOD" also failed to link as well. Stockfish seems to fail because by default when compiling with GCC the makefile uses -flto and LLD doesn't understand the GCC IR files. I think the COFF linker handles this by shelling out to the system linker in the case of MSVC LTO, and ELF should probably do the same.</div><div>I haven't looked into TTSIOD.</div><div><br></div><div><div>This seems to have caused some bad publicity: <a href="https://www.reddit.com/r/programming/comments/601kn9/trying_out_llvm_40s_lld_linker/">https://www.reddit.com/r/programming/comments/601kn9/trying_out_llvm_40s_lld_linker/</a></div></div><div>One user even comes away with this impression: "As you can see in the link, LLD is unable to link several projects. It's far from production ready."</div><div>(and I cannot blame them; LLD should "Just Work" with almost all major open-source software packages, and failing 3, including a very common one like libjpeg-turbo which is used by firefox and chromium, doesn't reflect well)</div><div>One user experiencing a segfault appears to have been kind enough to send us a bug report: <a href="https://bugs.llvm.org/show_bug.cgi?id=32341">https://bugs.llvm.org/show_bug.cgi?id=32341</a></div><div><br></div><div>-- Sean Silva</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>