[llvm-dev] Please dogfood LLD

[Sean Silva via llvm-dev]

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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170318/d918efbf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phonybfd.patch
Type: text/x-patch
Size: 926 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170318/d918efbf/attachment.bin>