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

From: Mark Millard via freebsd-toolchain <>
Date: Fri, 16 Jul 2021 13:41:45 -0700
On 2021-Jul-16, at 11:26, Mark Millard <marklmi at> wrote:

> On 2021-Jul-16, at 04:15, Mark Millard <marklmi at> wrote:
>> On 2021-Jul-16, at 03:23, Dimitry Andric <dim at> wrote:
>>> On 16 Jul 2021, at 02:21, Mark Millard via freebsd-toolchain <> wrote:
>>>> # c++ -v -o trivial trivial.cpp
>>>> FreeBSD clang version 12.0.1 ( 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/ --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.
>> 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.)
>> In other words, why is aarch64-unknown-freebsd14.0-ld
>> even listed in TargetSpecificExecutables for the system
>> toolchain's clang++ ?
>> 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.)
>> 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.
>>> See the Driver::GetProgramPath() function:
>> 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.
>>> 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?
>> # pkg which /usr/local/bin/aarch64-unknown-freebsd14.0-ld
>> /usr/local/bin/aarch64-unknown-freebsd14.0-ld was installed by package aarch64-binutils-2.33.1_4,1
>> # pkg delete aarch64-binutils
>> Checking integrity... done (0 conflicting)
>> Deinstallation has been requested for the following 3 packages (of 0 packages in the universe):
>> Installed packages to be REMOVED:
>>      aarch64-binutils: 2.33.1_4,1
>>      aarch64-gcc6: 6.5.0_3
>>      aarch64-gcc9: 9.3.0_1
>> Number of packages to be removed: 3
>> The operation will free 278 MiB.
>> Proceed with deinstalling packages? [y/N]: N
>> So /usr/local/bin/aarch64-unknown-freebsd14.0-ld
>> exists because I built and installed:
>> devel/freebsd-gcc6_at_aarch64
>> devel/freebsd-gcc9_at_aarch64
>> devel/binutils_at_aarch64
>>> 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.
> Another command line way to potentially control this might be
> use of: -fuse-ld=lld
> That might change the name looked for to: aarch64-unknown-freebsd14.0-lld
> and not match any existing toolchains.

I've confirmed the -fuse-ld=lld workaround and using it
when -flto is involved allows a build to complete instead
of getting the earlier-reported error.

This avoid fiddling with the path sequence via -B so I
prefer it over -B .

Mark Millard
marklmi at
( went
away in early 2018-Mar)
Received on Fri Jul 16 2021 - 20:41:45 UTC

Original text of this message