depends: Override host compilers for FreeBSD and OpenBSD #32716

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.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32716.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

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.

cc @vasild

Here is a CI build on FreeBSD 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:

diff --git a/depends/hosts/freebsd.mk b/depends/hosts/freebsd.mk
index 009d215f82f..0a9d8bb423d 100644
--- a/depends/hosts/freebsd.mk
+++ b/depends/hosts/freebsd.mk
@@ -7,25 +7,24 @@ freebsd_release_CXXFLAGS=$(freebsd_release_CFLAGS)
 freebsd_debug_CFLAGS=-O1 -g
 freebsd_debug_CXXFLAGS=$(freebsd_debug_CFLAGS)

+freebsd_CC=clang
+freebsd_CXX=clang++
+
+ifneq ($(host),$(build))
+freebsd_CC+=-target $(canonical_host)
+freebsd_CXX+=-target $(canonical_host)
+endif
+
 ifeq (86,$(findstring 86,$(build_arch)))
-i686_freebsd_CC=clang -m32
-i686_freebsd_CXX=clang++ -m32
 i686_freebsd_AR=ar
 i686_freebsd_RANLIB=ranlib
 i686_freebsd_NM=nm
 i686_freebsd_STRIP=strip

-x86_64_freebsd_CC=clang -m64
-x86_64_freebsd_CXX=clang++ -m64
 x86_64_freebsd_AR=ar
 x86_64_freebsd_RANLIB=ranlib
 x86_64_freebsd_NM=nm
 x86_64_freebsd_STRIP=strip
-else
-i686_freebsd_CC=$(default_host_CC) -m32
-i686_freebsd_CXX=$(default_host_CXX) -m32
-x86_64_freebsd_CC=$(default_host_CC) -m64
-x86_64_freebsd_CXX=$(default_host_CXX) -m64
 endif

 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 to default_host_{CC,CXX}, which resolves to gcc/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?

--- i/depends/hosts/default.mk
+++ w/depends/hosts/default.mk
@@ -3,6 +3,6 @@ host_toolchain:=$(host)-
 endif
 
-default_host_CC = $(host_toolchain)gcc
-default_host_CXX = $(host_toolchain)g++
+default_host_CC = $(host_toolchain)cc
+default_host_CXX = $(host_toolchain)c++
 default_host_AR = $(host_toolchain)ar
 default_host_RANLIB = $(host_toolchain)ranlib

That will address the root of the problem.

On Linux:

$ cc --version
cc (GCC) 13.2.1 20230801

$ c++ --version
c++ (GCC) 13.2.1 20230801

on FreeBSD:

$ cc --version
FreeBSD clang version 19.1.7

$ c++ --version
FreeBSD clang version 19.1.7

I tried @vasild's patch instead of the commit here on an aarch64 and x86 OpenBSD VM (on top of #31802), and it seems to work fine.

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:

$ guix shell --pure --container clang-toolchain gcc-toolchain
$ cc --version 
clang version 20.1.5
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /gnu/store/kjlzha1hhsdzawcnq2xig5cz7kpfwnna-clang-20.1.5/bin
$ c++ --version
c++ (GCC) 15.1.0
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Huh! An environment where 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 cc is clang and c++ 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 cc is clang and c++ 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?

Isn't this the case for our own Guix environment when building for macOS?

No idea, but if it is, then can it be fixed? If it is and cannot be fixed or is too hard to fix it, then maybe it would be better to have the depends build system support overriding the compiler. Then this overridability can be used from weird environments. That seems to be the natural way gmake, bsd make, autotools, CMake and possibly others work - to honor the CC and CXX variables from the environment where they are started. This would mean that instead of

default_host_CC = $(host_toolchain)cc

we can use

default_host_CC = $(host_toolchain)$(CC)

The CC variable is set by default in make to cc. Then in the weird environment:

cd depends
CC=whatever make

At the risk of further derailing this thread from FreeBSD and OpenBSD (sorry!), I also ran into a similar problem with not being able to override the compiler in depends. TLDR; built a nix dev environment that includes all llvm tooling (no gcc, g++) and was trying to do a depends build. This fails like so:

make -C depends NO_QT=1 MULTIPROCESS=1
make: Entering directory '/home/josie/bitcoin/depends'
Extracting native_capnp...
/home/josie/bitcoin/depends/sources/capnproto-cxx-1.2.0.tar.gz: OK
Preprocessing native_capnp...
Configuring native_capnp...
CMake Error at /nix/store/wphngc22a7aphbp5pi5jqmqlsqmisgn5-cmake-3.31.6/share/cmake-3.31/Modules/CMakeDetermineCXXCompiler.cmake:48 (message):
  Could not find compiler set in environment variable CXX:

  g++.

Call Stack (most recent call first):
  CMakeLists.txt:2 (project)

.. because g++ is being set as the default but doesn't exist in my toolchain. I was able to get around this with the following snippet (h/t @fanquake ):

make -C depends/ MULTIPROCESS=1 capnp default_host_CC=clang default_host_CXX=clang++

.. which did work, but I couldn't figure out how to do this override globally, e.g., something like:

make -C depends default_host_CC=clang default_host_CXX=clang++ -j$(nproc)

After reading through this thread, I think something like @vasild 's suggestion in #32716 (comment) is what I'm looking for. For my usecase currrently, I'm just symlinking gcc/g++ to clang/clang++ (which is basically what macOS does, iiuc?).

but I couldn't figure out how to do this override globally

shouldn't this just be CC=... CXX=..., like in CI (https://github.com/bitcoin/bitcoin/blob/ad654a4807cd584be9ffcd8640f628ab40cb5170/ci/test/00_setup_env_native_nowallet_libbitcoinkernel.sh#L13), or is this issue MULTIPROCESS=1 capnp specific?

but I couldn't figure out how to do this override globally

shouldn't this just be CC=... CXX=..., like in CI (

https://github.com/bitcoin/bitcoin/blob/ad654a4807cd584be9ffcd8640f628ab40cb5170/ci/test/00_setup_env_native_nowallet_libbitcoinkernel.sh#L13 ), or is this issue MULTIPROCESS=1 capnp specific?

Seems to be MULTIPROCESS=1-specific. e.g.:

docker run -it nixos/nix

# Start a shell in container with no `gcc`/`g++` present
nix-shell --pure -E 'with import <nixpkgs> {}; mkShellNoCC { buildInputs = [ cmake curl gnumake patch git cacert which clang coreutils binutils ]; }'

# In the nix shell
git clone --depth=1 https://github.com/bitcoin/bitcoin && cd bitcoin
make -C depends -j$(nproc) NO_QT=1 CC=clang CXX=clang++ MULTIPROCESS=1

shouldn't this just be CC=... CXX=...

Yes, I think it should be. But is not because currently depends/hosts/default.mk contains:

default_host_CC = $(host_toolchain)gcc
default_host_CXX = $(host_toolchain)g++

gcc and g++ are hardcoded there. The following would make it possible to override the C and C++ compiler from the environment:

-default_host_CC = $(host_toolchain)gcc
-default_host_CXX = $(host_toolchain)g++
+default_host_CC = $(host_toolchain)$(CC)
+default_host_CXX = $(host_toolchain)$(CXX)

The $(CC) and $(CXX) variables have meaningful defaults set by make itself, so we do not need to do something like "if CC is not set in the environment, then set it to whatever".

or is this issue MULTIPROCESS=1 capnp specific?

I don't think the issue is specific to multiprocess, but rather I'm running into the issue when trying to build multiprocess. I think the root cause is as @vasild mentions, i.e., hardcoding gcc/g++. Admittedly, it is weird that I'm hitting this with multiprocess but its because I am specifically trying to build in an environment without gcc/g++.

I was surprised that make -C depends -j$(nproc) CC=clang CXX=clang++ MULTIPROCESS=1 didn't work.

This also is related: https://codeberg.org/guix/guix/issues/556.

I was surprised that make -C depends -j$(nproc) CC=clang CXX=clang++ MULTIPROCESS=1 didn't work.

FWIW, on some systems, such as NetBSD, it may be necessary to be more specific about the compilers used to build native packages:

gmake -C depends MULTIPROCESS=1 build_CC=/usr/pkg/gcc14/bin/gcc build_CXX=/usr/pkg/gcc14/bin/g++ CC=/usr/pkg/gcc14/bin/gcc CXX=/usr/pkg/gcc14/bin/g++

This also is related: https://codeberg.org/guix/guix/issues/556.

Reading the discussion there, it seems like the behaviour is intentional.

There are more improvements we could make here, but we can take, and backport, the (simpler) current change as-is. Anything more will at least require some Guix changes.

Backported to 29.x in #32863.