[llvm-dev] Please dogfood LLD

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 16 14:24:54 PDT 2017


I think it'd be convenient if we had a clang build-time option to always
use ld.lld installed in the same directory as the clang executable, so that
their versions are always in-sync and we don't need to pass -fuse-ld=lld.

On Thu, Mar 16, 2017 at 2:15 PM, James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I agree, it seems like we ought to be installing and looking for lld as
> part of the compiler install directory (for example,
> /usr/lib/llvm-4.0/bin/{clang,lld}), rather than searching for it in the
> base system.
>
> On Thu, Mar 16, 2017 at 2:31 PM, Ed Maste via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On 16 March 2017 at 02:14, Sean Silva via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > I would not be
>> > surprised by older LLD and newer Clang causing issues, but the reverse
>> > Should Work.
>>
>> We'll soon have cases where there will be a LLD 4.0.0 /usr/bin/ld
>> provided by the base system, and Clang 4.1.0 /usr/local/bin/clang
>> installed from a package. It probably means we just need to have that
>> Clang use its own copy of LLD in the same package.
>>
>> It'll be great if we can detect and error on this case rather than
>> producing broken output though.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> _______________________________________________
> 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/llvm-dev/attachments/20170316/4653d88f/attachment.html>


More information about the llvm-dev mailing list