On 16 Jul 2021, at 13:15, Mark Millard via freebsd-toolchain <[email protected]> wrote: > > On 2021-Jul-16, at 03:23, Dimitry Andric <dim at FreeBSD.org> wrote: >> On 16 Jul 2021, at 02:21, Mark Millard via freebsd-toolchain >> <[email protected]> wrote: >>> # c++ -v -o trivial trivial.cpp >>> FreeBSD clang version 12.0.1 ([email protected]: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. > > 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.)
No, but maybe we should add a symlink? :)
(See also the discussion recently about the order of /usr/bin and
/usr/local/bin in the PATH. But be sure to have some popcorn ready. :)
> In other words, why is aarch64-unknown-freebsd14.0-ld
> even listed in TargetSpecificExecutables for the system
> toolchain's clang++ ?
This is because it is a usual practice on many operating systems, in
particular Linux of coourse. Cross tools are almost always installed
with triple prefixes.
The TargetSpecificExecutables list is filled using this function:
void Driver::generatePrefixedToolNames(
StringRef Tool, const ToolChain &TC,
SmallVectorImpl<std::string> &Names) const {
// FIXME: Needs a better variable than TargetTriple
Names.emplace_back((TargetTriple + "-" + Tool).str());
Names.emplace_back(Tool);
// Allow the discovery of tools prefixed with LLVM's default target triple.
std::string DefaultTargetTriple = llvm::sys::getDefaultTargetTriple();
if (DefaultTargetTriple != TargetTriple)
Names.emplace_back((DefaultTargetTriple + "-" + Tool).str());
}
E.g. it puts the 'tripled' version of the tool before the 'naked' tool.
> 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.)
Well, the question is how you would explicitly enable those alternates;
yet another command line option? In any case it would have to go via
upstream, as we don't really want more customized hacks in our version
of clang.
That said, I think I agree that the current behavior is not really what
FreeBSD users would expect, and it is not very likely that you would
want to actually call the GNU linker in /usr/local/bin/foobar-ld.bfd.
So that's going on my list of things-to-implement-and-submit-upstream.
-Dimitry
signature.asc
Description: Message signed with OpenPGP
