Re: libtool support for LLVM's LLD linker

[Ed Maste]

On 21 March 2017 at 18:25, Bob Friesenhahn <address@hidden> wrote:
>
> What bad things happen if libtool does not decide that the linker is GNU ld?

People at the Phoronix web site try out LLD[1], and report that LLD
fails when trying to link certain pieces of software when the failure
is really due to an invalid linker invocation :-)

Sean Silva analyzed some of the failures[2] and posted a snippet of
the ./configure output diff[3] for libjpeg-turbo. I think it may not
show the paste without being logged in, so I'll include the important
parts here:

diff --git a/home/sean/tmp/bfd.log b/home/sean/tmp/lld.log
-checking if the linker (/usr/bin/ld) is GNU ld... yes
+checking if the linker (/usr/bin/ld) is GNU ld... no
-checking whether -lc should be explicitly linked in... no
-checking how to hardcode library paths into programs... immediate
+checking how to hardcode library paths into programs... unsupported

This seems to be the usual case: libtool does not know which flags to
apply for some configuration (e.g. rpath or linking a shared library),
and the software fails to build.

> Does the situation improve if --with-gnu-ld is supplied as an argument to
> configure?  If this causes things to work, then it is a way for the ports
> system to cure the problem at configure-time.

Interesting - thanks for the suggestion. To fix some other software
LLD needs another workaround[4] to output "supported targets; elf" and
"supported emulations". I'm not sure if there's a command-line flag to
override this check, but will look more into that and try
--with-gnu-ld next week if others working on LLD don't get to it
first.

[1] http://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=3
[2] http://lists.llvm.org/pipermail/llvm-dev/2017-March/111283.html
[3] https://reviews.llvm.org/P7977
[4] https://reviews.llvm.org/D31208