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 13:15, Mark Millard via freebsd-toolchain <freebsd-toolchain@freebsd.org> 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 <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.
> 
> 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