Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things)

On 19/07/2021 13:35, Mark Millard via toolchain wrote:
> gcc is not documented to do automatically do such that I've
> found.

GCC is not Clang.  GCC does not allow dynamically choosing the target. 
If you want a GCC that targets aarch64-unknown-freebsd, then you must 
build a copy of GCC that targets that triple.  If you want a version of 
clang that targets aarch64-unknown-freebsd, then you pass that to the 
-target argument.  The clang driver will provide a *default* value for 
the -target argument if one is not provided.

>> -flto requires LLD.  You can force that with -fuse-ld=lld.  Clang then will only find things called [{target triple}-]ld.lld
> If I specify -flto (which I did), why is the command invalid
> by definition (produces an error message) and so require more
> command line options to correct the behavior to not get an
> error? Why should the installation or removal of a incompatible
> tool chain change the status of the system's clang++ command
> line?

Clang does not know if ld is lld.  It expects that the linker that you 
provide is compatible with the linker arguments that you provide.  If 
lld is installed as {target}-ld, or if no {target}-ld exists and lld is 
installed as {somewhere on the search path}/ld, then it will work.  If 
the linker installed on the search path is BFD or some other mostly 
compatible ld, then it will work unless -flto is or some other linker 
flag that is not compatible with that linker is specified.  I am aware 
of at least three other non-lld linkers that do support LTO with LLVM, 
clang doesn't know, for all possible linkers you might have installed, 
which ones support which flags.

> 
> (The message is far from an obvious one as well, complaining
> about a missing file path.)

Note that this error comes from your linker, not clang.  It is a bit odd 
that the base system clang tries to use the gold plugin but we don't 
install it.  It should probably check for the existence of LLVMgold.so 
and not pass it to the linker if it doesn't exist.

> There is another message from me where I note that I'd figured
> out the -fuse-ld=lld hack, although I omitted "ld." in the
> example: should have been aarch64-unknown-freebsd14.0-ld.lld .
> I'm actively using this technique because it seems to have the
> minimal other potential consequences.

If you do anything that depends on a specific linker or linker behaviour 
(e.g. LTO) then specifying the linker to use is good practice, not a 'hack'.


> In the industry, it is fairly normal for a tool chain to
> have a place unique to it that wins unless something
> special is specified. (And that is after lots of
> variations have been tried over the decades.) I've tried
> to illustrate that with gcc but it is just one point and
> I do not claim there is universal following of such.

It is also normal in the industry for a toolchain to be non-modular and 
to support a single target.  Both of these were considered anti-features 
by LLVM.

David