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

[Richard Smith via llvm-dev]

On Fri, Oct 28, 2016 at 12:50 PM, Renato Golin <renato.golin at linaro.org>
wrote:

> 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?
>

Either that or a flag that specifies to prefer the system's tools, with the
default behavior being to use LLVM's tools when possible.


> 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.


That problem already exists; we search various paths looking for tools,
libstdc++, and so on. It doesn't seem to be a particularly big deal in
practice, and it's easy to ask Clang to tell you what it actually selected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161028/f3d121db/attachment-0001.html>