[cfe-dev] [llvm-dev] LLD to be the default linker in Clang

Andrew Kelley via cfe-dev cfe-dev at lists.llvm.org
Fri Oct 28 11:44:13 PDT 2016


I did not realize LLD was already far enough along to use. I have a related
question: What about using LLD via library API?

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.



On Fri, Oct 28, 2016 at 12:17 PM, Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Folks,
>
> I'm creating a bootstrap buildbot on AArch64 with LLD and I just
> realised the "accepted" way to make clang call lld is to "symlink lld
> -> ld". I understand that's how every Linux system "chooses" the
> linker, but that makes deployment and validation quite cumbersome on
> GNU systems.
>
> I'd like to suggest a change in behaviour:
>
> // Some flag like --linker=<full path / bin on path>
> if (LinkerFlag) {
>   linker = Flag (linker);
>
> // triple != host
> } else if (CROSS_COMPILE) {
>   if (LLDSupports(triple))
>     linker = Find (LLD);
>   if (!linker)
>     linker = Find (triple-ld);
>   if (!linker)
>     ERROR; // *NOT* the system linker!
>
> // triple = host
> } else {
>   linker = Find (LLD);
>   if (!linker)
>     linker = Find (SYSLD); // OS-specific
>   if (!linker)
>     ERROR; // We tried!
> }
>
>
>   Rationale
>
> My reason is that, if you just build Clang, with or without LLD,
> everything works out of the box as you expect: Former uses LLD, latter
> uses the system's linker. If LLD is able to cross-compile to the
> target triple, and it's available, try that. Cross compilers should
> never use the system linker, as that's just silly.
>
> However, if you didn't build Clang or LLD and still want to force the
> linker (cross when clang gets it wrong, lld installed somewhere else,
> some non-sysroot alternative, ld when you have built lld), you'll need
> a flag. It doesn't really matter if GCC will ever use LLD, but it
> would be good to have Clang be able to specify which linker to use.
>
> We already have library flags, and we don't need an assembler flag, so
> the linker seems like the last option missing.
>
>
>   Use Case
>
> For example, it's perfectly reasonable to have GCC and Clang on the
> same system and to have LD and LLD installed / accessible. It's also
> perfectly reasonable to have GCC using LD and Clang using LLD on the
> same system. Today, that's not possible without changing the path for
> Clang and not GCC (cumbersome, to say the least).
>
> The environment above is *exactly* that of any buildbot trying to
> bootstrap Clang+LLD using GCC+LD. Iwant to have at least one for
> AArch64 and one for ARM, but it would be good to have the same thing
> for x86_64, too at the very least.
>
> I don't know much about FreeBSD, but they're moving LLD as the
> official linker in multiple platforms and they still have GCC/LD in
> ports. There will probably be corner cases...
>
>
>   Conclusion
>
> I think LLD is mature enough to be preferred over LD on the platforms
> it support, if available.
>
> Since it's not available by default in most of them, its existence
> means intention.
>
> Once it becomes available, having it means you should really use it.
>
> Looks like a no-brainer to me. Am I missing something?
>
> cheers,
> --renato
> _______________________________________________
> 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/cfe-dev/attachments/20161028/3e8e5f37/attachment.html>


More information about the cfe-dev mailing list