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
