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/07/2021 01:21, Mark Millard via freebsd-toolchain wrote:
> Context:
> 
> # uname -apKU
> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #10 main-n247756-348c41d1815d-dirty: Mon Jul  5 10:23:55 PDT 2021     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400025 1400025
> 
> 
> Showing a trivial example . . .
> 
> # cat trivial.cpp
> // # c++ -v -o trival trivial.cpp
> 
> int main() {
> }
> 
> # c++ -v
> 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
> 
> # 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
> CA72_16Gp_ZFS# c++ -v
> 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
> 
> Note the "/usr/local/bin/aarch64-unknown-freebsd14.0-ld" path
> for ld.
> 
> 
> I've an example where this usage leads to:
> 
> /usr/local/bin/aarch64-unknown-freebsd14.0-ld: /usr/bin/../lib/LLVMgold.so: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so"
> clang++: error: linker command failed with exit code 1 (use -v to see invocation)

This is the documented behaviour for clang when cross-compiling.  You 
can specify a target in one of two ways with clang:

  - Via the -target flag.
  - By invoking clang with a symlink named {target}-clang[++]

Clang will look for all of the tools in your path (or in the tree 
specified with -B if you provide an alternative location for tools).  If 
clang finds {target}-{tool name} then it will invoke this in preference 
to {tool name}.  This avoids situations where, for example, your system 
ld is BFD ld (or any other linker that doesn't support cross-linking) 
and you are cross compiling.

In general, if you are cross building anything and not specifying 
--sysroot (to tell it where to find headers and libraries for the 
target) and -B (to tell it where to find tools) then you are probably 
doing something wrong.

David