Alternative to #33562, which was adding a native FreeBSD job; however that had issues with permissions/caching, as well as potential determinism issues. This adds a FreeBSD cross job using Linux and Clang.
Would close #33438. The same changes here could also be used to produce FreeBSD binaries out of Guix.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
<!--85328a0da195eb286784d51f73fa0af9-->
🚧 At least one of the CI tasks failed.
<sub>Task lint: https://github.com/bitcoin/bitcoin/actions/runs/21630222694/job/62340895630</sub>
<sub>LLM reason (✨ experimental): Lint failure: a script lacks executable permission (ci/test/00_setup_env_freebsd_cross.sh) causing lint-files.py to fail.</sub>
<details><summary>Hints</summary>
Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:
Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.
Leave a comment here, if you need help tracking down a confusing failure.
</details>
103 | @@ -104,4 +104,17 @@ if [ -n "$XCODE_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${OSX_SDK_BASENAME}" ] 104 | tar -C "${DEPENDS_DIR}/SDKs" -xf "$OSX_SDK_PATH" 105 | fi 106 | 107 | +mkdir -p "${DEPENDS_DIR}/SDKs/freebsd-cross-${FREEBSD_VERSION}" 108 | + 109 | +FREEBSD_SDK_BASENAME="freebsd-cross-${XCODE_VERSION}" 110 | + 111 | +if [ -n "$FREEBSD_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" ]; then 112 | + FREEBSD_SDK_FILENAME="base-15.0.txz"
FREEBSD_SDK_FILENAME="base-${FREEBSD_VERSION}.txz"
Added
0 | @@ -1,31 +1,39 @@ 1 | +FREEBSD_VERSION=15.0
will this hard-code the version for everyone?
Still wondering about this :thinking:
Sorry, no, it shouldn't do. It's also possible for anyone to override this if needed i.e make -C depends/ HOST=x86_64-unknown-freebsd FREEBSD_VERSION=14.4.
The current assignment only allows overrides via command-line arguments, ignoring environment variables. This can be counter-intuitive. Suggesting the following change:
FREEBSD_VERSION ?= 15.0
7 | +export LC_ALL=C.UTF-8 8 | + 9 | +export CONTAINER_NAME=ci_freebsd_cross 10 | +export CI_IMAGE_NAME_TAG="mirror.gcr.io/ubuntu:24.04" 11 | +export APT_LLVM_V="21" 12 | +export FREEBSD_VERSION=15.0
maybe use 14.3 for now, to avoid the failure?
maybe use 14.3 for now, to avoid the failure?
Yea, that works, so I've pushed it up for now.
nice, this should catch the compile issues. Can't comment much on the build system changes, though
potential determinism issues
You can drop this from the OP, given #34093 (comment)
potential determinism issues
You can drop this from the OP, given #34093 (comment)
This refers to the alternative approach, which was using unpinned third-party deps, so I think the pull request description is correct.
103 | @@ -104,4 +104,17 @@ if [ -n "$XCODE_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${OSX_SDK_BASENAME}" ] 104 | tar -C "${DEPENDS_DIR}/SDKs" -xf "$OSX_SDK_PATH" 105 | fi 106 | 107 | +mkdir -p "${DEPENDS_DIR}/SDKs/freebsd-cross-${FREEBSD_VERSION}" 108 | + 109 | +FREEBSD_SDK_BASENAME="freebsd-cross-${XCODE_VERSION}"
FREEBSD_SDK_BASENAME="freebsd-cross-${FREEBSD_VERSION}"
Fixed
0 | @@ -1,31 +1,39 @@ 1 | +FREEBSD_VERSION=15.0 2 | +FREEBSD_SDK=$(SDK_PATH)/freebsd-cross-$(FREEBSD_VERSION)/
Would it be possible to support side-by-side installations of SDKs for different architectures (e.g., amd64 and arm64)
I've put the target into the SDK path, which should be enough to achieve that.
109 | +FREEBSD_SDK_BASENAME="freebsd-${HOST}-${FREEBSD_VERSION}" 110 | + 111 | +if [ -n "$FREEBSD_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" ]; then 112 | + FREEBSD_SDK_FILENAME="base-${FREEBSD_VERSION}.txz" 113 | + FREEBSD_SDK_PATH="${DEPENDS_DIR}/sdk-sources/${FREEBSD_SDK_FILENAME}" 114 | + if [ ! -f "$OSX_SDK_PATH" ]; then
if [ ! -f "$FREEBSD_SDK_PATH" ]; then
Fixed.
112 | + FREEBSD_SDK_FILENAME="base-${FREEBSD_VERSION}.txz" 113 | + FREEBSD_SDK_PATH="${DEPENDS_DIR}/sdk-sources/${FREEBSD_SDK_FILENAME}" 114 | + if [ ! -f "$OSX_SDK_PATH" ]; then 115 | + ${CI_RETRY_EXE} curl --location --fail "https://download.freebsd.org/releases/amd64/${FREEBSD_VERSION}-RELEASE/base.txz" -o "$FREEBSD_SDK_PATH" 116 | + fi 117 | + tar -C "${DEPENDS_DIR}/SDKs/freebsd-cross-${FREEBSD_VERSION}" -xf "$FREEBSD_SDK_PATH"
tar -C "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" -xf "$FREEBSD_SDK_PATH"
This seems to be from a previous diff.
103 | @@ -104,4 +104,17 @@ if [ -n "$XCODE_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${OSX_SDK_BASENAME}" ] 104 | tar -C "${DEPENDS_DIR}/SDKs" -xf "$OSX_SDK_PATH" 105 | fi 106 | 107 | +mkdir -p "${DEPENDS_DIR}/SDKs/freebsd-${HOST}-${FREEBSD_VERSION}" 108 | + 109 | +FREEBSD_SDK_BASENAME="freebsd-${HOST}-${FREEBSD_VERSION}" 110 | + 111 | +if [ -n "$FREEBSD_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" ]; then
To avoid duplication we could use this in making the dir above - which should likely be after we're checking for it, i.e.
FREEBSD_SDK_BASENAME="freebsd-${HOST}-${FREEBSD_VERSION}"
if [ -n "$FREEBSD_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" ]; then
mkdir -p "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}"
6 | +# prior to 1af314465e5dfe3e8baa839a32a72e83c04f26ef, first released in v4.2.90. 7 | +# At the time of writing, GNU Make v4.2.1 is still being used in supported 8 | +# distro releases. 9 | +# 10 | +# Source: https://lists.gnu.org/archive/html/bug-make/2017-11/msg00017.html 11 | +clang_prog=$(shell $(SHELL) $(.SHELLFLAGS) "command -v clang")
nit: other names start with freebsd_ prefix
This is on purpose.
103 | @@ -104,4 +104,16 @@ if [ -n "$XCODE_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${OSX_SDK_BASENAME}" ] 104 | tar -C "${DEPENDS_DIR}/SDKs" -xf "$OSX_SDK_PATH" 105 | fi 106 | 107 | +FREEBSD_SDK_BASENAME="freebsd-${HOST}-${FREEBSD_VERSION}" 108 | + 109 | +if [ -n "$FREEBSD_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" ]; then 110 | + FREEBSD_SDK_FILENAME="base-${FREEBSD_VERSION}.txz"
we already have a basename above, could we use it here?
FREEBSD_SDK_FILENAME="${FREEBSD_SDK_BASENAME}-base.txz"
111 | + FREEBSD_SDK_PATH="${DEPENDS_DIR}/sdk-sources/${FREEBSD_SDK_FILENAME}" 112 | + if [ ! -f "$FREEBSD_SDK_PATH" ]; then 113 | + ${CI_RETRY_EXE} curl --location --fail "https://download.freebsd.org/releases/amd64/${FREEBSD_VERSION}-RELEASE/base.txz" -o "$FREEBSD_SDK_PATH" 114 | + fi 115 | + mkdir -p "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" 116 | + tar -C "${DEPENDS_DIR}/SDKs/freebsd-${HOST}-${FREEBSD_VERSION}" -xf "$FREEBSD_SDK_PATH"
we could use the FREEBSD_SDK_BASENAME here as well:
tar -C "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" -xf "$FREEBSD_SDK_PATH"
539 | @@ -540,6 +540,13 @@ jobs: 540 | timeout-minutes: 120 541 | file-env: './ci/test/00_setup_env_native_msan.sh' 542 | 543 | + 544 | + - name: 'FreeBSD Cross'
could we group it with the other cross task? https://github.com/bitcoin/bitcoin/blob/e8df2be3b9fbd8cfdf10e3a5f0e7c344d10a2673/.github/workflows/ci.yml#L483-L487
Sure.
539 | @@ -540,6 +540,13 @@ jobs: 540 | timeout-minutes: 120 541 | file-env: './ci/test/00_setup_env_native_msan.sh' 542 | 543 | + 544 | + - name: 'FreeBSD Cross' 545 | + cirrus-runner: 'ghcr.io/cirruslabs/ubuntu-runner-amd64:24.04-md'
if we're just compiling (not even running tests), would a small instance suffice?
cirrus-runner: 'ghcr.io/cirruslabs/ubuntu-runner-amd64:24.04-sm'
19 | + -DREDUCE_EXPORTS=ON \ 20 | + -DBUILD_GUI=OFF \ 21 | + -DWITH_USDT=OFF \ 22 | +" 23 | +export RUN_UNIT_TESTS="false" 24 | +export RUN_FUNCTIONAL_TESTS="false"
Are we planning on enabling the tests later? Having BSD tests would have helped with #34256
nit: based on other usages the values don't have to be strings: https://github.com/bitcoin/bitcoin/blob/e4c04f7759b0b390189410f5ef3ad5faa5354698/ci/test/00_setup_env_mac_native_fuzz.sh#L15-L17
Are we planning on enabling the tests later?
Not sure. This is just adding cross compilation.
22 | + 23 | +freebsd_CC=$(clang_prog) --target=$(host) \ 24 | + --sysroot=$(FREEBSD_SDK) 25 | + 26 | +freebsd_CXX=$(clangxx_prog) --target=$(host) \ 27 | + --sysroot=$(FREEBSD_SDK) -stdlib=libc++
isn't libc++ the default here?
--sysroot=$(FREEBSD_SDK)
10 | +# Source: https://lists.gnu.org/archive/html/bug-make/2017-11/msg00017.html 11 | +clang_prog=$(shell $(SHELL) $(.SHELLFLAGS) "command -v clang") 12 | +clangxx_prog=$(shell $(SHELL) $(.SHELLFLAGS) "command -v clang++") 13 | + 14 | +freebsd_AR=$(shell $(SHELL) $(.SHELLFLAGS) "command -v llvm-ar") 15 | +freebsd_DSYMUTIL=$(shell $(SHELL) $(.SHELLFLAGS) "command -v dsymutil")
Based on https://llvm.org/docs/CommandGuide/dsymutil.html this seems to be a macOS bundle format, probably not needed here
Right. On FreeBSD, command -v dsymutil returns nothing,
Dropped.
8 | + 9 | +export CONTAINER_NAME=ci_freebsd_cross 10 | +export CI_IMAGE_NAME_TAG="mirror.gcr.io/ubuntu:24.04" 11 | +export APT_LLVM_V="21" 12 | +export FREEBSD_VERSION=15.0 13 | +export PACKAGES="clang-${APT_LLVM_V} llvm-${APT_LLVM_V} lld"
doesn't lld need the same version?
export PACKAGES="clang-${APT_LLVM_V} llvm-${APT_LLVM_V} lld-${APT_LLVM_V}"
this will probably also need:
diff --git a/ci/test/01_base_install.sh b/ci/test/01_base_install.sh
--- a/ci/test/01_base_install.sh (revision e8df2be3b9fbd8cfdf10e3a5f0e7c344d10a2673)
+++ b/ci/test/01_base_install.sh (date 1773780463181)
@@ -53,6 +53,7 @@
if [ -n "${APT_LLVM_V}" ]; then
update-alternatives --install /usr/bin/clang++ clang++ "/usr/bin/clang++-${APT_LLVM_V}" 100
update-alternatives --install /usr/bin/clang clang "/usr/bin/clang-${APT_LLVM_V}" 100
+ update-alternatives --install /usr/bin/ld.lld ld.lld "/usr/bin/ld.lld-${APT_LLVM_V}" 100
update-alternatives --install /usr/bin/llvm-symbolizer llvm-symbolizer "/usr/bin/llvm-symbolizer-${APT_LLVM_V}" 100
fi
In this compilation, I'd expect all these versions to work, but I've added this for consistency.
10 | +export CI_IMAGE_NAME_TAG="mirror.gcr.io/ubuntu:24.04" 11 | +export APT_LLVM_V="21" 12 | +export FREEBSD_VERSION=15.0 13 | +export PACKAGES="clang-${APT_LLVM_V} llvm-${APT_LLVM_V} lld" 14 | +export HOST=x86_64-unknown-freebsd 15 | +export DEP_OPTS="build_CC=clang build_CXX=clang++ AR=llvm-ar-${APT_LLVM_V} STRIP=llvm-strip-${APT_LLVM_V} NM=llvm-nm-${APT_LLVM_V} RANLIB=llvm-ranlib-${APT_LLVM_V} NO_QT=1"
Do we need to define CC and CXX here, too, isn't the freebsd_CC/freebsd_CXX enough?
build_CC and build_CXX are for native tools.
11 | +export APT_LLVM_V="21" 12 | +export FREEBSD_VERSION=15.0 13 | +export PACKAGES="clang-${APT_LLVM_V} llvm-${APT_LLVM_V} lld" 14 | +export HOST=x86_64-unknown-freebsd 15 | +export DEP_OPTS="build_CC=clang build_CXX=clang++ AR=llvm-ar-${APT_LLVM_V} STRIP=llvm-strip-${APT_LLVM_V} NM=llvm-nm-${APT_LLVM_V} RANLIB=llvm-ranlib-${APT_LLVM_V} NO_QT=1" 16 | +export GOAL="install"
This is already the default: https://github.com/bitcoin/bitcoin/blob/580e9eefe39f2f94695e1a22437c6ac47a1664e6/ci/test/00_setup_env.sh#L63
Yep, and we are explicit in any case, in all CI configs.
103 | @@ -104,4 +104,16 @@ if [ -n "$XCODE_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${OSX_SDK_BASENAME}" ] 104 | tar -C "${DEPENDS_DIR}/SDKs" -xf "$OSX_SDK_PATH" 105 | fi 106 | 107 | +FREEBSD_SDK_BASENAME="freebsd-${HOST}-${FREEBSD_VERSION}" 108 | + 109 | +if [ -n "$FREEBSD_VERSION" ] && [ ! -d "${DEPENDS_DIR}/SDKs/${FREEBSD_SDK_BASENAME}" ]; then 110 | + FREEBSD_SDK_FILENAME="base-${FREEBSD_VERSION}.txz" 111 | + FREEBSD_SDK_PATH="${DEPENDS_DIR}/sdk-sources/${FREEBSD_SDK_FILENAME}"
Should sdk-sources also be included in the explicit CI caches?
Left a few more comments. Concept ACK on adding FreeBSD cross-compilation coverage to CI.
It looks like the first commit introduces a regression for FreeBSD users cross-compiling to other architectures:
$ gmake -j 8 -C depends NO_QT=1 HOST=i686-unknown-freebsd
$ cmake -B build --toolchain depends/i686-unknown-freebsd/toolchain.cmake
$ cmake --build build -t bitcoind
[323/323] Linking CXX executable bin/bitcoind
FAILED: [code=1] bin/bitcoind
: && /usr/bin/clang++ --target=i686-unknown-freebsd -O2 -O2 -g -fuse-ld=lld -fstack-protector-all -fcf-protection=full -fstack-clash-protection -Wl,-z,relro -Wl,-z,now -Wl,-z,separate-code -fPIE -pie -Xlinker --dependency-file=src/CMakeFiles/bitcoind.dir/link.d src/CMakeFiles/bitcoind.dir/bitcoind.cpp.o src/CMakeFiles/bitcoind.dir/init/bitcoind.cpp.o -o bin/bitcoind lib/libbitcoin_node.a lib/libbitcoin_wallet.a lib/libbitcoin_zmq.a /home/hebasto/dev/bitcoin/depends/i686-unknown-freebsd/lib/libzmq.a src/libleveldb.a src/libcrc32c.a src/libminisketch.a /home/hebasto/dev/bitcoin/depends/i686-unknown-freebsd/lib/libevent_extra.a /home/hebasto/dev/bitcoin/depends/i686-unknown-freebsd/lib/libevent_pthreads.a /home/hebasto/dev/bitcoin/depends/i686-unknown-freebsd/lib/libevent_core.a -lpthread lib/libbitcoin_common.a lib/libbitcoin_util.a lib/libbitcoin_clientversion.a lib/libbitcoin_consensus.a lib/libbitcoin_crypto.a src/secp256k1/lib/libsecp256k1.a src/univalue/libunivalue.a -pthread /home/hebasto/dev/bitcoin/depends/i686-unknown-freebsd/lib/libsqlite3.a && :
ld.lld: error: /home/hebasto/dev/bitcoin/depends/i686-unknown-freebsd/lib/libsqlite3.a(sqlite3.o) is incompatible with elf_i386_fbsd
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
Concept ACK.
It looks like the first commit introduces a regression for FreeBSD users cross-compiling to other architectures: HOST=i686-unknown-freebsd
What SDK are you using for i386; I don't see a 15.0 release under https://download.freebsd.org/releases/i386/?
If I use the 14.4 version, and your commands, it builds fine (compiling on x86_64):
clang --version
Ubuntu clang version 18.1.3 (1ubuntu1)
Target: x86_64-pc-linux-gnu
...
file build/bin/bitcoind
build/bin/bitcoind: ELF 32-bit LSB pie executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.4, FreeBSD-style, with debug_info, not stripped
It looks like the first commit introduces a regression for FreeBSD users cross-compiling to other architectures: HOST=i686-unknown-freebsd
What SDK are you using for
i386; I don't see a 15.0 release under https://download.freebsd.org/releases/i386/?
Currently, on the master branch, there is no need to specify an SDK to cross-compile on FreeBSD x86_64 to i686.
6 | + 7 | +export LC_ALL=C.UTF-8 8 | + 9 | +export CONTAINER_NAME=ci_freebsd_cross 10 | +export CI_IMAGE_NAME_TAG="mirror.gcr.io/ubuntu:24.04" 11 | +export APT_LLVM_V="21"
nit: Could add a trailing comment that this aims to use the clang version that freebsd is using?
This is currently 21 because I forgot to change it to 22. The LLVM version used by FreeBSD 15 is 19.x. We can try pin to 19, or just use 22, I don't think I mind either way. One downside of pinning to older, could be poorer support in the apt repo (for current, or newer images).
Ok, interesting. I guess you are right that the clang version doesn't really matter here. Maybe one could use the default vanilla system clang (whatever version that is) of the IMAGE_NAME_TAG. This would allow dropping the APT_LLVM_V, having one less place to bump. But again, this doesn't really matter, so anything is fine here.
Ok, I'll leave this for now, see if there are any other opinons.
15 | +export DEP_OPTS="build_CC=clang build_CXX=clang++ AR=llvm-ar-${APT_LLVM_V} STRIP=llvm-strip-${APT_LLVM_V} NM=llvm-nm-${APT_LLVM_V} RANLIB=llvm-ranlib-${APT_LLVM_V} NO_QT=1" 16 | +export GOAL="install" 17 | +export BITCOIN_CONFIG="\ 18 | + --preset=dev-mode \ 19 | + -DREDUCE_EXPORTS=ON \ 20 | + -DBUILD_GUI=OFF \
nit: Could add a comment why the gui is disabled. Just saying there is a compile failure (or so) is fine.
I'll add a comment, for reference at least one Qt compile failure is:
ld.lld: error: undefined symbol: QKqueueFileSystemWatcherEngine::create(QObject*)
>>> referenced by qfilesystemwatcher.cpp
>>> qfilesystemwatcher.cpp.o:(QFileSystemWatcher::QFileSystemWatcher(QObject*)) in archive /root/ci_scratch/depends/aarch64-unknown-freebsd/lib/libQt6Core.a
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Could be fixed with the following patch:
--- a/depends/packages/qt.mk
+++ b/depends/packages/qt.mk
@@ -167,6 +167,8 @@ $(package)_config_env += CXX="$$($(package)_cxx)"
$(package)_config_env_darwin := OBJC="$$($(package)_cc)"
$(package)_config_env_darwin += OBJCXX="$$($(package)_cxx)"
+$(package)_config_opts_freebsd += -no-feature-inotify
+
$(package)_cmake_opts := -DCMAKE_PREFIX_PATH=$(host_prefix)
$(package)_cmake_opts += -DQT_FEATURE_cxx20=ON
$(package)_cmake_opts += -DQT_GENERATE_SBOM=OFF
Added.
Could be fixed with the following patch:
Did this work for you? The build is still broken here, after applying the above.
Could be fixed with the following patch:
Did this work for you? The build is still broken here, after applying the above.
I successfully built on Ubuntu 25.10. -no-feature-inotify is required to enabling compiling of the required source file:
qt_internal_extend_target(Core CONDITION QT_FEATURE_filesystemwatcher AND UNIX AND NOT MACOS AND NOT QT_FEATURE_inotify AND (APPLE OR FREEBSD OR NETBSD OR OPENBSD)
SOURCES
io/qfilesystemwatcher_kqueue.cpp io/qfilesystemwatcher_kqueue_p.h
)
Concept ACK
Though, I am not familiar with freebsd, nor the build system, so I can't really review this
Approach ACK 65379bb8d0ebcbf5251f0bc0727019d2ba95be3c. I need to run a few more tests before the final ACK.
The same changes here could also be used to produce FreeBSD binaries out of Guix.
https://download.freebsd.org/releases/amd64/15.0-RELEASE/base.txz doesn't seem to include static libraries like libc.a, libc++.a and libcxxrt.a. How should we handle this for the release binaries?
How should we handle this for the release binaries?
I'll look at that when we look at adding FreeBSD bins to releases, not as part of this PR.
ACK 65379bb8d0ebcbf5251f0bc0727019d2ba95be3c. I've cross-compiled on Ubuntu 25.10 for FreeBSD 14.4 and 15.0. The former binaries (bitcoind, test_bitcoin and bitcoin-qt) were tested on FreeBSD 14.4 locally.
0 | @@ -1,31 +1,38 @@ 1 | +FREEBSD_VERSION ?= 15.0 2 | +FREEBSD_SDK=$(SDK_PATH)/freebsd-$(host)-$(FREEBSD_VERSION)/ 3 | + 4 | +# We can't just use $(shell command -v clang) because GNU Make handles builtins 5 | +# in a special way and doesn't know that `command` is a POSIX-standard builtin 6 | +# prior to 1af314465e5dfe3e8baa839a32a72e83c04f26ef, first released in v4.2.90. 7 | +# At the time of writing, GNU Make v4.2.1 is still being used in supported 8 | +# distro releases.
I'm curious: which specific distributions used for cross-compiling are you referring to?
The comment isn't being introduced here, it's from darwin.mk. I'd imagine it was in regards to Debian, or Ubuntu 20.04 (at the time) Maybe we can drop this at this point, as I don't think it's likely that Ubuntu 20.04 is being used to cross-compile for macOS. See #34923.