[llvm-dev] Please dogfood LLD

[Khem Raj via llvm-dev]

On Sat, Mar 18, 2017 at 6:07 PM Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Thu, Mar 16, 2017 at 11:26 AM, Ed Maste via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On 15 March 2017 at 16:34, Carsten Mattner <carstenmattner at gmail.com>
> wrote:
> >
> > If FreeBSD's libtool is patched to be aware of the base ld=lld,
> > would this still be true?
>
> Yes, for the same reason Joerg points out in another reply in this
> thread - some software packages are going to include in their
> configure scripts parts of whatever libtool version existed on the
> machine used by a developer to produce a release.
>
>
>
> It looks like we've picked up Phoronix's attention:
> http://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=3
> Note that they did this test in the most brutal possible way (replacing
> /usr/bin/ld with LLD).
>
> It seems that they found that a few packages failed to build with LLD.
>
> I tried reproducing the libjpeg-turbo one and it seems likely to be due to
> differences in configure. This is the diff: https://reviews.llvm.org/P7977
>
> 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 `).
>
> 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: https://reviews.llvm.org/P7978
> See the thread "lld status on the freebsd ports" where Rafael shared his
> findings from the freebsd ports, inclusing these hacks.
>
> 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
> ​.
>

​perhaps​ its better to provide fixes to these applications to not look for
tool specific strings. If you put such knobs into tools then you have to
live with it for life of the tool. musl libc had similar problems where it
exposed assumptions about libc specific implementation, musl's adherence to
not mimic the behavior ended up in cleaning up many of the packages and
making them more portable.

Problems you are describing seems to be also in similar realm, I would
rather suggest to provide fixes for the packages instead of fixing lld.

> ​
> ​
>

>
> 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.
> I haven't looked into TTSIOD.
>
> This seems to have caused some bad publicity: https://www.reddit.
> com/r/programming/comments/601kn9/trying_out_llvm_40s_lld_linker/
> 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."
> (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)
> One user experiencing a segfault appears to have been kind enough to send
> us a bug report: https://bugs.llvm.org/show_bug.cgi?id=32341
>
> -- Sean Silva
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170319/1164acf7/attachment.html>