[cfe-dev] [RFC] Recognize -fuse-ld={bfd, gold, lld} but don't prepend "ld." or "ld64." for other values

[Eric Christopher via cfe-dev]

On Wed, Jun 3, 2020 at 6:10 AM David Chisnall via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On 02/06/2020 19:47, Fangrui Song via cfe-dev wrote:
> > If they use a relative path, they can't be benefiting from ld. prefix
>
> This depends on how they specify the path.  If they specify a path for
> the linker via -fuse-ld, they don't get the prefix.  Most cross-compile
> toolchains that I've seen don't do that.  Instead, they use -B to
> specify a path to find *all* of the tools and then use
> -fuse-ld={lld,gold,bfd,proprietary linker's name}.
>
> That is the use case I'm concerned about breaking.  The behaviour of -B
> is to prepend a search path, but still fall back to the default paths if
> a tool is not found there.  For example, if I have:
>
> /usr/bin/lld
> /my/custom/sdk/bin/ld.lld
>
> If I run:
>
> $ clang -B /my/custom/sdk/bin/ -fuse-ld=lld ...
>
> Today, I will run my cross-compile toolchain's linker.  With your
> proposed change, I will run my system LLD install.  As a user, I will
> see very confusing error messages from the system linker if it can't
> handle my cross-compile target.  Worse, I may see a binary linked with a
> linker that defaults to a different linker script, but still produces
> some output.
>
>
This is a good point. The change should take -B into account I think.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200603/1420791c/attachment-0001.html>