[cfe-dev] [RFC] Recognize -fuse-ld={bfd, gold, lld} but don't prepend "ld." or "ld64." for other values
Fangrui Song via cfe-dev
cfe-dev at lists.llvm.org
Tue Jun 16 15:24:41 PDT 2020
On 2020-06-03, Fangrui Song wrote:
>On 2020-06-03, David Chisnall via cfe-dev 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.
>>
>>David
>
>-fuse-ld={bfd,gold,lld} is compatible with the previous behavior.
>
>Do you propose that:
>
>* -fuse-ld={bfd,gold.lld} should find "ld.{bfd,gold,lld}" in COMPILER_PATH
>* all -fuse-ld=word should find "word" in COMPILER_PATH
>* -fuse-ld=relative/path should find "relative/path" in PATH?
Thoughts?
More information about the cfe-dev
mailing list