<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">As far as I know, -fuse-ld has been copied from gcc, which documents it here: <a href="https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-fuse-ld_003dbfd" class="">https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-fuse-ld_003dbfd</a>. Obviously we can make any alias we want, but the gcc spelling should still be supported.<div class=""><br class=""></div><div class="">-Dimitry<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6 Jul 2020, at 21:52, Petr Hosek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">-f<flag> options are typically used for flags that control code generation, that's what <a href="https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html" class="">https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html</a> says as well. Neither of these flags are related to code generation. Have you considered using just -use-ld= and -ld-path= and deprecating -fuse-ld= altogether? I think that would also be more consistent with other --*-path flags we have such as --cuda-path= or ptxas-path=.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 12:36 PM Fangrui Song via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-07-06, David Blaikie wrote:<br class="">
>The design then is to support composing -fuse-ld and -fld-path? So<br class="">
>things like -fuse-ld=gold<br class="">
>-fld-path=some-thing-like-gold-but-maybe-not-quite (if I want the<br class="">
>clang driver gold-specific behavior, but to use my custom linker<br class="">
>binary?)?<br class="">
<br class="">
Yes. -fuse-ld= specifies the flavor: bfd, gold, lld.<br class="">
This can affect clang driver decisions on linker options.<br class="">
(see <a href="https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Fuchsia.cpp#L57" rel="noreferrer" target="_blank" class="">https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Fuchsia.cpp#L57</a> )<br class="">
<br class="">
When -fuse-ld=lld is specified, you can still specify<br class="">
-fld-path= to use a non-standard path, e.g.  -fuse-ld=lld -fld-path=/tmp/opt/bin/ld.lld<br class="">
<br class="">
>On Wed, Jul 1, 2020 at 5:54 PM Fangrui Song via cfe-dev<br class="">
><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">
>><br class="">
>> On 2020-06-16, Fangrui Song wrote:<br class="">
>> >On 2020-06-03, Fangrui Song wrote:<br class="">
>> >>On 2020-06-03, David Chisnall via cfe-dev wrote:<br class="">
>> >>>On 02/06/2020 19:47, Fangrui Song via cfe-dev wrote:<br class="">
>> >>>>If they use a relative path, they can't be benefiting from ld. prefix<br class="">
>> >>><br class="">
>> >>>This depends on how they specify the path.  If they specify a path<br class="">
>> >>>for the linker via -fuse-ld, they don't get the prefix.  Most<br class="">
>> >>>cross-compile toolchains that I've seen don't do that.  Instead,<br class="">
>> >>>they use -B to specify a path to find *all* of the tools and then<br class="">
>> >>>use -fuse-ld={lld,gold,bfd,proprietary linker's name}.<br class="">
>> >>><br class="">
>> >>>That is the use case I'm concerned about breaking.  The behaviour<br class="">
>> >>>of -B is to prepend a search path, but still fall back to the<br class="">
>> >>>default paths if a tool is not found there.  For example, if I<br class="">
>> >>>have:<br class="">
>> >>><br class="">
>> >>>/usr/bin/lld<br class="">
>> >>>/my/custom/sdk/bin/ld.lld<br class="">
>> >>><br class="">
>> >>>If I run:<br class="">
>> >>><br class="">
>> >>>$ clang -B /my/custom/sdk/bin/ -fuse-ld=lld ...<br class="">
>> >>><br class="">
>> >>>Today, I will run my cross-compile toolchain's linker.  With your<br class="">
>> >>>proposed change, I will run my system LLD install.  As a user, I<br class="">
>> >>>will see very confusing error messages from the system linker if<br class="">
>> >>>it can't handle my cross-compile target.  Worse, I may see a<br class="">
>> >>>binary linked with a linker that defaults to a different linker<br class="">
>> >>>script, but still produces some output.<br class="">
>> >>><br class="">
>> >>>David<br class="">
>> >><br class="">
>> >>-fuse-ld={bfd,gold,lld} is compatible with the previous behavior.<br class="">
>> >><br class="">
>> >>Do you propose that:<br class="">
>> >><br class="">
>> >>* -fuse-ld={bfd,gold.lld} should find "ld.{bfd,gold,lld}" in COMPILER_PATH<br class="">
>> >>* all -fuse-ld=word should find "word" in COMPILER_PATH<br class="">
>> >>* -fuse-ld=relative/path should find "relative/path" in PATH?<br class="">
>> ><br class="">
>> >Thoughts?<br class="">
>><br class="">
>> Created <a href="https://reviews.llvm.org/D83015" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D83015</a> [Driver] Add -fld-path= and deprecate -fuse-ld=/abs/path and -fuse-ld=rel/path<br class="">
>><br class="">
>> This should resolve jyknight's concern.<br class="">
>><br class="">
>> I think GCC will be happy with whatever reasonable consensus we can reach:<br class="">
>> <a href="https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549236.html" rel="noreferrer" target="_blank" class="">https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549236.html</a><br class="">
>> _______________________________________________<br class="">
>> cfe-dev mailing list<br class="">
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></div></body></html>