Date: Fri, 16 Jul 2021 13:41:45 -0700 From: Mark Millard via freebsd-toolchain <freebsd-toolchain@freebsd.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) Message-ID: <CBEA9132-19F7-45B5-A1A9-153074813AEE@yahoo.com> In-Reply-To: <CB9B9992-68F6-45D3-B210-A73E527DDBEE@yahoo.com> References: <7073D16F-4505-4948-8232-A9618DF2FE5F.ref@yahoo.com> <7073D16F-4505-4948-8232-A9618DF2FE5F@yahoo.com> <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> <CB9B9992-68F6-45D3-B210-A73E527DDBEE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jul-16, at 11:26, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Jul-16, at 04:15, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> On 2021-Jul-16, at 03:23, Dimitry Andric <dim at FreeBSD.org> wrote: >>=20 >>> 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=3Dnon-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=3Dgdb -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=3D4.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 >>>=20 >>> 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. >>=20 >> 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.) >>=20 >> In other words, why is aarch64-unknown-freebsd14.0-ld >> even listed in TargetSpecificExecutables for the system >> toolchain's clang++ ? >>=20 >> 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.) >>=20 >> 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. >>=20 >>> See the Driver::GetProgramPath() function: >>> = https://github.com/llvm/llvm-project/blob/release/12.x/clang/lib/Driver/Dr= iver.cpp#L4981 >>=20 >> 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. >>=20 >> 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. >>=20 >>> 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. >>>=20 >>> 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? >>=20 >> # 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 >>=20 >> # pkg delete aarch64-binutils >> Checking integrity... done (0 conflicting) >> Deinstallation has been requested for the following 3 packages (of 0 = packages in the universe): >>=20 >> Installed packages to be REMOVED: >> aarch64-binutils: 2.33.1_4,1 >> aarch64-gcc6: 6.5.0_3 >> aarch64-gcc9: 9.3.0_1 >>=20 >> Number of packages to be removed: 3 >>=20 >> The operation will free 278 MiB. >>=20 >> Proceed with deinstalling packages? [y/N]: N >>=20 >> So /usr/local/bin/aarch64-unknown-freebsd14.0-ld >> exists because I built and installed: >>=20 >> devel/freebsd-gcc6@aarch64 >> devel/freebsd-gcc9@aarch64 >> devel/binutils@aarch64 >>=20 >>> 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". >>>=20 >>> 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. >>=20 >> 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. >=20 > Another command line way to potentially control this might be > use of: -fuse-ld=3Dlld >=20 > That might change the name looked for to: = aarch64-unknown-freebsd14.0-lld > and not match any existing toolchains. >=20 I've confirmed the -fuse-ld=3Dlld 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 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CBEA9132-19F7-45B5-A1A9-153074813AEE>