build: Bump g++ minimum supported version to 13 #36042

At some point, it may be fine to drop support for older vanilla systems not shipping with at least GCC 13.

(For this bump, only C++20 std::format will become available, but this bump should also pave the way for C++23.)

This patch will only be released in version 33.x, or later, next year (2027).

For reference:

• https://packages.ubuntu.com/noble/g++ (g++-13)
• https://packages.debian.org/trixie/g++ (g++-14)
• CentOS-like 8/9/10 ship recent GCC via appstream (dnf install -y gcc-toolset-15)
• Free/Open/Net*BSD ship a recent GCC
• OpenSuse Leap and Tumbleweed ship with g++ 15 https://software.opensuse.org/package/gcc15-c++

On operating systems where the minimum GCC version is not shipped by default, the user would have to use Clang, or install GCC in a different way. For example:

• Debian Bookworm could use https://packages.debian.org/bookworm/clang-22
• Ubuntu 22.04 would have to use a general alternative:
• PPA, https://apt.llvm.org/ (for Clang), brew, nix, guix, or compile GCC from source, ...

Obviously, downloading pre-compiled releases or compiling previous release branches is unaffected by this change.

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--006a51241073e994b41acfe9ec718e94-->

External sites

• Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36042
• Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36042.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36042#author-ralph

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #36036 _{<img src="https://drahtbot.space/ack_count/bitcoin/bitcoin/36036.svg">} (build: Bump clang minimum supported version to 19 by maflcko)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task NetBSD Cross: https://github.com/bitcoin/bitcoin/actions/runs/32388090156/job/96487376676} _{LLM reason (✨ experimental): CI failed because CMake’s try-compile for text formatting errored with fatal error: 'format' file not found (missing C++ <format> header).}

<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>

Hmm, looks like netbsd-cross is a CI blocker for this? Not sure how to proceed here, because netbsd ci coverage may be useful, but no real user is doing netbsd-cross (I expect all users are running on native netbsd). But native netbsd isn't an option for CI ... :man_shrugging:

but no real user is doing netbsd-cross (I expect all users are running on native netbsd). But native netbsd isn't an option for CI ...

Are you saying this does work natively on NetBSD? I'd expect it to fail the same way (given NetBSD 11 ships GCC 12.5.0 which doesn't support std::format), and the CI here is giving us the coverage we want (showing this would break compilation for native NetBSD users)?

NetBSD also has recent GCC in packages, so it should work natively on NetBSD. But I don't really know an answer to the meta question, or how to proceed here, which is why this is in draft and removed from the milestone.

References:

• https://www.netbsd.org/docs/software/3rdparty/: "gcc: Version in tree: 12.5.0/14.3.0"
• https://wiki.netbsd.org/releng/netbsd-11/ marks "netbsd-11 is not buildable with gcc 14 or newer" as fixed, but https://mail-index.netbsd.org/port-alpha/2026/08/03/msg001496.html ... ?
• Edit: https://gcc.gnu.org/gcc-12/: "(This release series is no longer supported.)" ...

I guess somebody (maybe @hebasto?) could test a newer version of GCC natively, to determine which compiler/flag combo is required for std::format, and then update the build instructions. Could be good to do in any case, if NetBSD users are currently using GCC 12.x.

I guess somebody (maybe @hebasto?) could test a newer version of GCC natively, to determine which compiler/flag combo is required for std::format, and then update the build instructions. Could be good to do in any case, if NetBSD users are currently using GCC 12.x.

Yes, it's possible to install a newer GCC compiler and configure the build system to use it (similar to what was documented prior to 9b85c9814d1d5b1ef9caedc25dc336dacb887dcc).

For example, on my NetBSD 11.0 system:

$ sudo pkgin install gcc15
$ cmake --preset dev-mode -DCMAKE_C_COMPILER=/usr/pkg/gcc15/bin/gcc -DCMAKE_CXX_COMPILER=/usr/pkg/gcc15/bin/g++ -DWITH_USDT=OFF -DENABLE_IPC=OFF

However, there is a minor issue caused by the base system and pkgsrc using different versions of libstdc++:

/usr/bin/ld: warning: libstdc++.so.9, needed by /usr/pkg/lib/libzmq.so, may conflict with libstdc++.so.7

and

$ ldd build_dev_mode/bin/bitcoind
build_dev_mode/bin/bitcoind:
	-lzmq.5 => /usr/pkg/lib/libzmq.so.5
	-lrt.1 => /usr/lib/librt.so.1
	-lc.12 => /usr/lib/libc.so.12
	-lpthread.1 => /usr/lib/libpthread.so.1
	-lstdc++.9 => /usr/lib/libstdc++.so.9
	-lm.0 => /usr/lib/libm.so.0
	-lgcc_s.1 => /usr/pkg/gcc15/lib/./libgcc_s.so.1
	/usr/pkg/lib/libsqlite3.so => /usr/pkg/lib/libsqlite3.so
	-lstdc++.7 => /usr/pkg/gcc15/lib/./libstdc++.so.7

However, there is a minor issue caused by the base system and pkgsrc using different versions of libstdc++:

So the same issue previously existed on NetBSD 10? So the only way to compile on NetBSD is with depends (or self-compiling all deps)?

However, there is a minor issue caused by the base system and pkgsrc using different versions of libstdc++:

So the same issue previously existed on NetBSD 10?

Yes.

So the only way to compile on NetBSD is with depends (or self-compiling all deps)?

Those linker warnings seem harmless, though.

As for "self-compiling all deps", only the C++ deps from pkgsrc actually need to be rebuilt. For an example of this, see https://github.com/hebasto/bitcoin-core-nightly/pull/117.

Concept ACK.

Related: https://gcc.gnu.org/pipermail/gcc/2026-September/248875.html:

The GCC 13 branch is now closed, no further changes can be pushed there.

the older netbsd packages will be nuked, so I am not sure how to proceed here. Possibly this needs full caching for the manual install of the netbsd gcc package, so this is still blocked on netbsd.

Concept ACK

Went ahead and dropped NetBSD-cross from the GHA matrix. While it is possible to keep and maintain it, it would be tedious, with questionable benefit, given that the task hasn't found a meaningful issue unique to the NetBSD-cross task.

We already had a situation before the NetBSD 11.0 release where NetBSD’s base compiler did not meet our minimum requirements. Back then, the NetBSD build notes provided instructions for installing a newer compiler. Moreover, due to a bug in capnproto, it seems prudent to recommend GCC 14 and skip GCC 13.

Went ahead and dropped NetBSD-cross from the GHA matrix.

I agree with that. Its value has been moderate recently, as most NetBSD-specific issues have been caught by running the tests elsewhere.

I hope we can proceed with this PR and undraft it, as GCC 12 is currently broken on some platforms anyway.

I hope we can proceed with this PR and undraft it

Ok, I'll think if it makes sense to git revert 9b85c9814d1d5b1ef9caedc25dc336dacb887dcc (with gcc14), and then undraft