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 Jul 2021, at 02:21, Mark Millard via freebsd-toolchain <freebsd-toolchain@freebsd.org> wrote:
> # c++ -v -o trivial trivial.cpp
> FreeBSD clang version 12.0.1 (git@github.com:llvm/llvm-project.git llvmorg-12.0.1-rc2-0-ge7dac564cd0e)
> Target: aarch64-unknown-freebsd14.0
> Thread model: posix
> InstalledDir: /usr/bin
> "/usr/bin/c++" -cc1 -triple aarch64-unknown-freebsd14.0 -emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name trivial.cpp -mrelocation-model static -mframe-pointer=non-leaf -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu generic -target-feature +neon -target-abi aapcs -fallow-half-arguments-and-returns -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/lib/clang/12.0.1 -internal-isystem /usr/include/c++/v1 -fdeprecated-macro -fdebug-compilation-dir /usr/home/root/c_tests -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -faddrsig -o /tmp/trivial-5d90b5.o -x c++ trivial.cpp
> clang -cc1 version 12.0.1 based upon LLVM 12.0.1 default target aarch64-unknown-freebsd14.0
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include/c++/v1
> /usr/lib/clang/12.0.1/include
> /usr/include
> End of search list.
> "/usr/local/bin/aarch64-unknown-freebsd14.0-ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o trivial /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/trivial-5d90b5.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o

Yes, this is an unfortunate (and sometimes unwanted) side effect of the
way the clang driver searches for its linker(s). It prefers "target
specific executables" (meaning, those beginning with the target triple)
above generic executables, when searching for linkers, assemblers and
other external tools.

See the Driver::GetProgramPath() function:
https://github.com/llvm/llvm-project/blob/release/12.x/clang/lib/Driver/Driver.cpp#L4981

In short, if it finds aarch64-unknown-freebsd14.0-$TOOL in your PATH, it
will prefer that over $TOOL, even if the 'naked' $TOOL would be found in
an earlier PATH component.

For programs like ld, as and such, these will be found if you install
the devel/binutils port with an arch-specific FLAVOR. In this case, I
assume this was because you installed a CROSS_TOOLCHAIN package such as
freebsd9-gcc, or directly installed the aarch64-binutils package?

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.

-Dimitry