When building depends on FreeBSD/OpenBSD aarch64, the host compilers default to default_host_{CC,CXX}, which resolves to gcc/g++. This is incorrect on these systems, where Clang is the default system compiler.
To ensure proper compiler selection, this PR adopts the same approach used for darwin:https://github.com/bitcoin/bitcoin/blob/c1d4253d316ea627f46b26e395d7b48842258381/depends/builders/darwin.mk#L12-L14
Fixes #32691.
When building depends on FreeBSD/OpenBSD `aarch64`, the host compilers
default to `default_host_{CC,CXX}`, which resolves to `gcc`/`g++`. This
is incorrect on these systems, where Clang is the default system
compiler.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32716.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | Sjors |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
ACK 4f10a57671c19cacca630b2401e42a213aacff1b
I tested that this fixes #32691 on an aarch64 OpenBSD VM, and doesn’t break anything on an x86 VM.
I didn’t test FreeBSD.
While testing this I noticed the depends build doesn’t bother creating qt. It’s not obvious to me why that is and doesn’t seem to be documented. The non-depends instructions for *BSD do include qt6.
aarch64 with depends: https://github.com/hebasto/bitcoin-core-nightly/actions/runs/15568752551/job/43839203600.
Since gcc (and thus $(host_toolchain)gcc) is basically never the right option for these, I’m wondering if we should just do something like:
0diff --git a/depends/hosts/freebsd.mk b/depends/hosts/freebsd.mk
1index 009d215f82f..0a9d8bb423d 100644
2--- a/depends/hosts/freebsd.mk
3+++ b/depends/hosts/freebsd.mk
4@@ -7,25 +7,24 @@ freebsd_release_CXXFLAGS=$(freebsd_release_CFLAGS)
5 freebsd_debug_CFLAGS=-O1 -g
6 freebsd_debug_CXXFLAGS=$(freebsd_debug_CFLAGS)
7
8+freebsd_CC=clang
9+freebsd_CXX=clang++
10+
11+ifneq ($(host),$(build))
12+freebsd_CC+=-target $(canonical_host)
13+freebsd_CXX+=-target $(canonical_host)
14+endif
15+
16 ifeq (86,$(findstring 86,$(build_arch)))
17-i686_freebsd_CC=clang -m32
18-i686_freebsd_CXX=clang++ -m32
19 i686_freebsd_AR=ar
20 i686_freebsd_RANLIB=ranlib
21 i686_freebsd_NM=nm
22 i686_freebsd_STRIP=strip
23
24-x86_64_freebsd_CC=clang -m64
25-x86_64_freebsd_CXX=clang++ -m64
26 x86_64_freebsd_AR=ar
27 x86_64_freebsd_RANLIB=ranlib
28 x86_64_freebsd_NM=nm
29 x86_64_freebsd_STRIP=strip
30-else
31-i686_freebsd_CC=$(default_host_CC) -m32
32-i686_freebsd_CXX=$(default_host_CXX) -m32
33-x86_64_freebsd_CC=$(default_host_CC) -m64
34-x86_64_freebsd_CXX=$(default_host_CXX) -m64
35 endif
36
37 freebsd_cmake_system_name=FreeBSD
Since gcc (and thus
$(host_toolchain)gcc) is basically never the right option for these, I’m wondering if we should just do something like…
I’d considered this option and another one. I chose the current approach for two reasons: (a) it results in a minimal diff, and (b) it avoids changing compiler flags on the x86_64 and i686 build platforms.
When building depends on FreeBSD/OpenBSD
aarch64, the host compilers default todefault_host_{CC,CXX}, which resolves togcc/g++
This is the root of the problem ^^^
Since gcc (and thus
$(host_toolchain)gcc) is basically never the right option for these
Exactly.
Is it not possible to use cc/c++ by default?
0--- i/depends/hosts/default.mk
1+++ w/depends/hosts/default.mk
2@@ -3,6 +3,6 @@ host_toolchain:=$(host)-
3 endif
4
5-default_host_CC = $(host_toolchain)gcc
6-default_host_CXX = $(host_toolchain)g++
7+default_host_CC = $(host_toolchain)cc
8+default_host_CXX = $(host_toolchain)c++
9 default_host_AR = $(host_toolchain)ar
10 default_host_RANLIB = $(host_toolchain)ranlib
That will address the root of the problem.
On Linux:
0$ cc --version
1cc (GCC) 13.2.1 20230801
2
3$ c++ --version
4c++ (GCC) 13.2.1 20230801
on FreeBSD:
0$ cc --version
1FreeBSD clang version 19.1.7
2
3$ c++ --version
4FreeBSD clang version 19.1.7
On Linux: c++ (GCC) 13.2.1 20230801
Just note that you can’t assume c++ is GCC on Linux. There are Linux distros built on LLVM/Clang, like Chimera, but using c++ could be a better default.
Is it not possible to use
cc/c++by default?
There is a risk of mixing C and C++ compilers from different toolchains:
0$ guix shell --pure --container clang-toolchain gcc-toolchain
1$ cc --version
2clang version 20.1.5
3Target: aarch64-unknown-linux-gnu
4Thread model: posix
5InstalledDir: /gnu/store/kjlzha1hhsdzawcnq2xig5cz7kpfwnna-clang-20.1.5/bin
6$ c++ --version
7c++ (GCC) 15.1.0
8Copyright (C) 2025 Free Software Foundation, Inc.
9This is free software; see the source for copying conditions. There is NO
10warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
cc is clang and c++ is gcc is broken, IMO. CMake will also fail to build in such an environment, I guess.
Huh! An environment where
ccis clang andc++is gcc is broken, IMO. CMake will also fail to build in such an environment, I guess.
Agreed, I wouldn’t worry about that config.
I agree with using cc/c++ for the build == host case as that’s what the docs for both suggest. But I suggested the clang -target=foo above for the cross case because $(host)-cc doesn’t make sense.
Huh! An environment where
ccis clang andc++is gcc is broken, IMO. CMake will also fail to build in such an environment, I guess.Agreed, I wouldn’t worry about that config.
Isn’t this the case for our own Guix environment when building for macOS?