Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things)
- Reply: Mark Millard via freebsd-toolchain : "Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things)"
- In reply to: Mark Millard via freebsd-toolchain : "Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 16 Jul 2021 10:23:38 UTC
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