<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 3, 2020 at 6:10 AM David Chisnall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/06/2020 19:47, Fangrui Song via cfe-dev wrote:<br>
> If they use a relative path, they can't be benefiting from ld. prefix<br>
<br>
This depends on how they specify the path.  If they specify a path for <br>
the linker via -fuse-ld, they don't get the prefix.  Most cross-compile <br>
toolchains that I've seen don't do that.  Instead, they use -B to <br>
specify a path to find *all* of the tools and then use <br>
-fuse-ld={lld,gold,bfd,proprietary linker's name}.<br>
<br>
That is the use case I'm concerned about breaking.  The behaviour of -B <br>
is to prepend a search path, but still fall back to the default paths if <br>
a tool is not found there.  For example, if I have:<br>
<br>
/usr/bin/lld<br>
/my/custom/sdk/bin/ld.lld<br>
<br>
If I run:<br>
<br>
$ clang -B /my/custom/sdk/bin/ -fuse-ld=lld ...<br>
<br>
Today, I will run my cross-compile toolchain's linker.  With your <br>
proposed change, I will run my system LLD install.  As a user, I will <br>
see very confusing error messages from the system linker if it can't <br>
handle my cross-compile target.  Worse, I may see a binary linked with a <br>
linker that defaults to a different linker script, but still produces <br>
some output.<br><br></blockquote><div><br></div><div>This is a good point. The change should take -B into account I think.</div><div><br></div><div>-eric </div></div></div>