<div dir="ltr">I did not realize LLD was already far enough along to use. I have a related question: What about using LLD via library API?<div><br></div><div>I would love to link against LLD and call API functions instead of trying to find the system linker and spawning a child process and having different code for each system linker. If I could use LLD as a library that would be one less moving part in my compiler, one less potential thing that could go wrong for my users.<br><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 28, 2016 at 12:17 PM, Renato Golin 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Folks,<br>
<br>
I'm creating a bootstrap buildbot on AArch64 with LLD and I just<br>
realised the "accepted" way to make clang call lld is to "symlink lld<br>
-> ld". I understand that's how every Linux system "chooses" the<br>
linker, but that makes deployment and validation quite cumbersome on<br>
GNU systems.<br>
<br>
I'd like to suggest a change in behaviour:<br>
<br>
// Some flag like --linker=<full path / bin on path><br>
if (LinkerFlag) {<br>
linker = Flag (linker);<br>
<br>
// triple != host<br>
} else if (CROSS_COMPILE) {<br>
if (LLDSupports(triple))<br>
linker = Find (LLD);<br>
if (!linker)<br>
linker = Find (triple-ld);<br>
if (!linker)<br>
ERROR; // *NOT* the system linker!<br>
<br>
// triple = host<br>
} else {<br>
linker = Find (LLD);<br>
if (!linker)<br>
linker = Find (SYSLD); // OS-specific<br>
if (!linker)<br>
ERROR; // We tried!<br>
}<br>
<br>
<br>
Rationale<br>
<br>
My reason is that, if you just build Clang, with or without LLD,<br>
everything works out of the box as you expect: Former uses LLD, latter<br>
uses the system's linker. If LLD is able to cross-compile to the<br>
target triple, and it's available, try that. Cross compilers should<br>
never use the system linker, as that's just silly.<br>
<br>
However, if you didn't build Clang or LLD and still want to force the<br>
linker (cross when clang gets it wrong, lld installed somewhere else,<br>
some non-sysroot alternative, ld when you have built lld), you'll need<br>
a flag. It doesn't really matter if GCC will ever use LLD, but it<br>
would be good to have Clang be able to specify which linker to use.<br>
<br>
We already have library flags, and we don't need an assembler flag, so<br>
the linker seems like the last option missing.<br>
<br>
<br>
Use Case<br>
<br>
For example, it's perfectly reasonable to have GCC and Clang on the<br>
same system and to have LD and LLD installed / accessible. It's also<br>
perfectly reasonable to have GCC using LD and Clang using LLD on the<br>
same system. Today, that's not possible without changing the path for<br>
Clang and not GCC (cumbersome, to say the least).<br>
<br>
The environment above is *exactly* that of any buildbot trying to<br>
bootstrap Clang+LLD using GCC+LD. Iwant to have at least one for<br>
AArch64 and one for ARM, but it would be good to have the same thing<br>
for x86_64, too at the very least.<br>
<br>
I don't know much about FreeBSD, but they're moving LLD as the<br>
official linker in multiple platforms and they still have GCC/LD in<br>
ports. There will probably be corner cases...<br>
<br>
<br>
Conclusion<br>
<br>
I think LLD is mature enough to be preferred over LD on the platforms<br>
it support, if available.<br>
<br>
Since it's not available by default in most of them, its existence<br>
means intention.<br>
<br>
Once it becomes available, having it means you should really use it.<br>
<br>
Looks like a no-brainer to me. Am I missing something?<br>
<br>
cheers,<br>
--renato<br>
______________________________<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>
</blockquote></div><br></div></div></div></div>