<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 28, 2016 at 10:38 AM, 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"><span class="">On 28 October 2016 at 18:12, Ed Maste <<a href="mailto:emaste@freebsd.org">emaste@freebsd.org</a>> wrote:<br>
> It should be possible to search the path for ld.lld first, then ld,<br>
> but to me it seems like it will just be more confusing.<br>
<br>
</span>Hum, for me it would be less confusing. :)<br>
<br>
GCC uses bfd by default, LLVM uses LLD. If you want to change, use -fuse-ld.<br></blockquote><div><br></div><div>I don't think that's a fair comparison. GCC uses the system linker by default (whatever 'ld' happens to name). If ld is a symlink to lld, then GCC uses lld by default.</div><div><br></div><div>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.</div><div><br></div><div>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. 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.</div><div><br></div><div>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)?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What would be confusing in this scenario?<br>
<span class=""><br>
<br>
> Clang's current approach (ld from $PATH by default, or ld.arg from<br>
> -fuse-ld=arg) suits us in FreeBSD. Today we have:<br>
>     /usr/bin/ld.bfd (GNU ld 2.17.50)<br>
>     /usr/bin/ld (ld.bfd symlink)<br>
><br>
> We'll soon add<br>
>     /usr/bin/ld.lld<br>
<br>
</span>This seems like a simple enough approach. I guess my problem is more<br>
about building toolchains than shipping them.<br>
<span class=""><br>
<br>
> The only downside of -fuse-ld= that I'm aware of affects GCC only, not<br>
> Clang: GCC accepts only -fuse-ld=bfd and -fuse-ld=gold, and Davide's<br>
> patch to add -fuse-ld=lld was met with hostility. But that shouldn't<br>
> have any effect on Clang.<br>
<br>
</span>Just had a look at the thread. Some silly comments were expected, but<br>
I think Davide has withdrawn his patch too early.<br>
<br>
AFAIK, there's absolutely nothing in the GCC license, moto and<br>
copyright statements that forbid the usage of a non-GNU linker, and<br>
the argument "lld has bugs" is pointless.<br>
<br>
I would try again.<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>