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

On 16/07/2021 12:15, Mark Millard via freebsd-toolchain wrote:
> As far as I know the /usr/bin/clang++ related FreeBSD
> toolchain never has a file aarch64-unknown-freebsd14.0-ld
> in FreeBSD. (And similarly fr other suffices than ld.)

There is nothing FreeBSD-specific in this behaviour in clang.  If 
someone wanted to provide a different search behaviour for the clang in 
the base system then that would be possible, but in general I am 
strongly opposed to any special casing of behaviour in the system 
compiler.  It's already incredibly annoying that the system compiler 
doesn't search /usr/local/include and /usr/local/lib so everything I 
build on FreeBSD needs to be explicitly told 'yes please do actually 
search the place where the system installed libraries, thanks'.

> In other words, why is aarch64-unknown-freebsd14.0-ld
> even listed in TargetSpecificExecutables for the system
> toolchain's clang++ ?

It isn't.  It is part of the generic search logic.  The search logic 
says, when compiling for {target triple}, prefer {target triple}-{tool 
name} over {tool name}.  When the clang driver looks for ld, it looks for

> I would argue that the default FreeBSD system toolchain
> configuration/operation should be adjusted/patched to not
> have automatic defaults that cause parts of that toolchain
> to not be used even though they are present, just because
> some unrelated/independent port(s) have been installed that
> are a different toolchain. (Explicitly enabling/allowing
> alternate matches may well be reasonable.)

The only way of doing this would be to completely remove all search 
logic and hard-code the paths.

> 
> As far as I know, there is no guarantee of compatibility
> with the gcc/g++/gnu related toolchain, with the error
> message that I reported being an example for attempted
> -flto use.

-flto requires LLD.  You can force that with -fuse-ld=lld.  Clang then 
will only find things called [{target triple}-]ld.lld

>> See the Driver::GetProgramPath() function:
>> https://github.com/llvm/llvm-project/blob/release/12.x/clang/lib/Driver/Driver.cpp#L4981
> It looks like if there was an implcit/automatic -B /usr/bin
> when /usr/bin/clang++ is the native FreeBSD toolchain one,
> that the problem would be avoided.
> 
> But, as, stands, that has to be done explicitly on the
> command lines in order to tell clang++ to use its own
> related FreeBSD toolchain instead of using one from
> ports.

But then we'd have a divergence between the system compiler and clang 
installed any other way.  It is expected behaviour that if I install a 
tool prefixed by the target triple then it will be used in preference to 
the system one.


>> Note that the native binutils package does not cause these problems,
>> since it prefixes its tools with $arch-portbld-freebsd14.0. E.g., the
>> 'vendor' field of the triple is set to "portbld", not "unknown".
>>
>> I guess the flavored binutils packages do use the "unknown" vendor field
>> to avoid installation conflicts. But at some point this should be
>> resolved: either all binutils ports should use the "portbld" vendor, or
>> all of them should use "unknown", but this mixing is causing trouble, in
>> my opinion.
> It has been all portbld at times in the past. That mix is also a
> problem. 3 distinct naming structures are needed, not just 2, in
> order to prevent mixing from occurring without some form of
> explicit request for a mix.

Setting the default target triple in the base system compiler to use 
freebsd as the vendor would avoid this problem: Unless you explicitly 
install something as {arch}-freebsd-freebsd[version]-{tool} then the 
base system clang won't use it.

David