clang 20 needs the real linker name

[wosch]

Summary

I tried to cross compile FreeBSD on macOS. I choose the clang20 from homebrew and got the error message:

• libsys.so.7.full ---

Building shared library libsys.so.7
[...]
clang: error: invalid linker name in argument '--ld-path=lld'

• [libsys.so.7.full] Error code 1

Apparently, the workaround in share/mk/bsd.sys.mk with mapping ld.lld -> lld no longer works

[jrtc27]

This looks odd. How were you trying to build? Have you seen https://github.com/freebsd/freebsd-src/commit/81fc74fd26da2f75c3010595db7a706c3e28d95b and its parent?

[jrtc27]

(By "this is odd" I mean "this change is definitely not right and will break other things even if it happens to end up producing a working build for you", so it's important to understand what exactly the problem you're seeing is rather than just deleting bits of code until your specific system is happy)

[wosch]

In D52330#1194788, @jrtc27 wrote:

This looks odd. How were you trying to build? Have you seen https://github.com/freebsd/freebsd-src/commit/81fc74fd26da2f75c3010595db7a706c3e28d95b and its parent?

my env setup:

---

#!/bin/sh

set -a

PATH=/opt/homebrew/opt/llvm@20/bin:/opt/homebrew/opt/lld@20/bin:/opt/homebrew/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin

CC=clang
CXX=clang++
CPP=clang-cpp
XCC=clang
XCXX=clang++
XCPP=clang-cpp
XLD=ld.lld

./tools/build/make.py -j10 TARGET=arm64 TARGET_ARCH=aarch64 buildworld

[jrtc27]

And what happens if you ls /opt/homebrew/opt/lld@20/bin?

[wosch]

In D52330#1195007, @jrtc27 wrote:

And what happens if you ls /opt/homebrew/opt/lld@20/bin?

$ ls -l /opt/homebrew/opt/lld@20/bin
total 128
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 ld.lld -> lld
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 ld64.lld -> lld
-r-xr-xr-x 1 wosch admin 62160 Sep 1 20:33 lld
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 lld-link -> lld
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 wasm-ld -> lld

$ /opt/homebrew/opt/lld@20/bin/ld.lld --version
Homebrew LLD 20.1.8 (compatible with GNU linkers)

calling “ldd” directly gives an error

$ /opt/homebrew/opt/lld@20/bin/lld --version
lld is a generic driver.
Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead
echo $?
1

[jrtc27]

In D52330#1195266, @wosch wrote:

In D52330#1195007, @jrtc27 wrote:

And what happens if you ls /opt/homebrew/opt/lld@20/bin?

$ ls -l /opt/homebrew/opt/lld@20/bin
total 128
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 ld.lld -> lld
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 ld64.lld -> lld
-r-xr-xr-x 1 wosch admin 62160 Sep 1 20:33 lld
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 lld-link -> lld
lrwxrwxr-x 1 wosch admin 3 Jul 9 01:06 wasm-ld -> lld

$ /opt/homebrew/opt/lld@20/bin/ld.lld --version
Homebrew LLD 20.1.8 (compatible with GNU linkers)

calling “ldd” directly gives an error

$ /opt/homebrew/opt/lld@20/bin/lld --version
lld is a generic driver.
Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead
echo $?
1

Yeah but that's not new.

[wosch]

fix make keyword typo (.elseif <-> .elif)

[wosch]

Ok, it is very easy to reproduce the issue on FreeBSD itself:

time make LD=ld.lld -j$(nproc) buildworld
real 0m30.111s
echo $?
2

• _bootstrap-tools-usr.bin/fortune/strfile ---

cc: error: invalid linker name in argument '--ld-path=lld'

• [strfile.full] Error code 1

Actually, I think the whole section about CLANG should be removed. Nobody compiles freebsd15-current with clang12 or older.

[jrtc27]

Ok so yeah there is the assumption that you're not doing that. Probably the correct fix is to drop the :S/^ld.//1W. But the other point to make is that your script is unnecessary, just pass --cross-toolchain=llvm@20 and it'll set all the X* variables for you to values that are known to work (because that's what CI is using), and you don't need to mess with PATH to make that work. You also do not need to set CC explicitly unless you really want to override the defaults, which I doubt.

[jrtc27]

And to be clear, as far as I can tell, absolutely nothing has changed in Clang to make Clang 20 any less happy with this configuration than Clang 12; that is, I believe using Clang 12 with that configuration when this was committed would have been just as broken, and so adding any new version-specific behaviour is inappropriate (and so the subject and body of this review are misguided).