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

On 2021-Jul-19, at 02:57, David Chisnall <theraven at FreeBSD.org> wrote:

> 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'.

https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options
reports that gcc does not look in those places with file name prefixes
for cpp, cc1, or ld. It makes no mention of looking based on a prefix
ending in text analogous to: aarch64-unknown-freebsd14.0-

So there are no words about such names having priority either.

And gcc uses /usr/lib/gcc/ and /usr/local/lib/gcc/ in preference
to using PATH entries as prefixes, stopping on the first match
found.

(This and other wording support later comments about
a fairly common industry practice.)

>> 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

gcc is not documented to do automatically do such that I've
found.

>> 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.

See the likes of what gcc is documented to do for an
example from the industry that need not match files from
other tool chains because the search starts with special
places for the specific toolchain and accepts matches
found in those places in preference to other places.

>> 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

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?

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

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.

>>> 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.

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.

>>> 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.

Yep, relative to this matching of files issue anyway.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)