On 21 March 2017 at 18:25, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> 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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
