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

[Renato Golin via cfe-dev]

On 28 October 2016 at 20:35, Richard Smith <richard at metafoo.co.uk> wrote:
> That's actually part of a much larger pattern: Clang is currently set up to
> act as a drop-in replacement for the system compiler. That means we use
> libstdc++ (not libc++) by default on targets where it's the default C++
> standard library, we use libgcc_s (not compiler-rt) by default on targets
> where it's the default compiler runtime, and so on. That strategy has worked
> well in getting us to where we are today.

Agreed! And I still need this very much to work.


> But our needs today aren't the same as they were a few years ago; we don't
> need to prove ourselves as much as we used to, and while we should keep
> supporting the target defaults for the above components, perhaps it's time
> that we start to prefer using LLVM components where available.

My feelings exactly.


> At the very
> least, I don't see a good reason why we would ever want to use libgcc_s in a
> situation where compiler-rt (and libunwind) are available -- libgcc_s does
> not contain some functions that LLVM implicitly adds calls to.

That's another dead-lock we need to solve, yes. :(


> Perhaps we should have a flag to specify whether we prefer the canonical
> tools and components for the target, or whether we prefer LLVM's versions
> when available (falling back to the target components if not)?

Hum, I had't thought of this...

Do you mean a flag that would (try) to use as much of LLVM as
possible, and fall back to the system's tools when unavailable?

I like the idea very much, but I wonder the kind of spurious bugs
we'll see if one tool suddenly doesn't get built, or change location,
or $PATH changes.

cheers,
--renato