[32.x] Bump to 32.0rc1 #36246

sedited commented at 8:46 AM on September 14, 2026: contributor

No description provided.

DrahtBot added the label Backport on Sep 14, 2026

DrahtBot commented at 8:46 AM on September 14, 2026: contributor

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

Code Coverage & Benchmarks

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

Reviews

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

Type	Reviewers
ACK	hebasto, fanquake

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

build: Bump to 32.0rc1 b4eafed80e

release: Generate man pages 6f132cc337

release: Generate bitcoin.conf b8e7c8c575

doc: Point release notes to 32.0 wiki draft 27d0d4fb3a

sedited force-pushed on Sep 14, 2026

fanquake added this to the milestone 32.0 on Sep 14, 2026

DrahtBot added the label CI failed on Sep 14, 2026

fanquake commented at 10:08 AM on September 14, 2026: member

https://github.com/bitcoin/bitcoin/actions/runs/34824778560/job/103914394388?pr=36246#step:11:5620:

+ ./contrib/devtools/clang-format-diff.py -binary=clang-format-23 -p1 -i -v
Formatting src/clientversion.cpp
+ git --no-pager diff --exit-code
diff --git a/src/clientversion.cpp b/src/clientversion.cpp
index 222dafb..1bb1332 100644
--- a/src/clientversion.cpp
+++ b/src/clientversion.cpp
@@ -22,7 +22,6 @@ using util::Join;
 const std::string UA_NAME("Satoshi");
 
 
-#include <bitcoin-build-info.h>
 // The <bitcoin-build-info.h>, which is generated by the build environment (cmake/script/GenerateBuildInfo.cmake),
 // could contain only one line of the following:
 //   - "#define BUILD_GIT_TAG ...", if the top commit is tagged
^^^ ⚠️ Failure generated from IWYU
+ echo '^^^ ⚠️ Failure generated from IWYU'
+ false

Not sure why IWYU is failing. cc @hebasto.

in CMakeLists.txt:34 in 27d0d4fb3a outdated

  32 | +set(CLIENT_VERSION_MINOR 0)
  33 |  set(CLIENT_VERSION_BUILD 0)
  34 | -set(CLIENT_VERSION_RC 0)
  35 | -set(CLIENT_VERSION_IS_RELEASE "false")
  36 | +set(CLIENT_VERSION_RC 1)
  37 | +set(CLIENT_VERSION_IS_RELEASE "true")

hebasto commented at 10:44 AM on September 14, 2026:

Not sure why IWYU is failing. cc @hebasto.

This change makes BUILD_GIT_COMMIT (defined in <bitcoin-build-info.h>) unused in src/clientversion.cpp, which causes IWYU to suggest removing #include <bitcoin-build-info.h>.

Let's tell IWYU to always keep it:

--- a/src/clientversion.cpp
+++ b/src/clientversion.cpp
@@ -22,7 +22,7 @@ using util::Join;
 const std::string UA_NAME("Satoshi");
 
 
-#include <bitcoin-build-info.h>
+#include <bitcoin-build-info.h> // IWYU pragma: keep
 // The <bitcoin-build-info.h>, which is generated by the build environment (cmake/script/GenerateBuildInfo.cmake),
 // could contain only one line of the following:
 //   - "#define BUILD_GIT_TAG ...", if the top commit is tagged

sedited commented at 10:54 AM on September 14, 2026:

I see, can you open this to master and I'll backport it here?

hebasto commented at 10:57 AM on September 14, 2026:

I see, can you open this to master and I'll backport it here?

On it.

hebasto commented at 11:06 AM on September 14, 2026:

I see, can you open this to master and I'll backport it here?

#36247.

sedited commented at 11:35 AM on September 14, 2026:

Backported.

fanquake referenced this in commit adca0a9740 on Sep 14, 2026

iwyu: Always keep `bitcoin-build-info.h` header

Macros from the `bitcoin-build-info.h` header may not be used in
`src/clientversion.cpp` depending on the `CLIENT_VERSION_IS_RELEASE`
macro value.

Therefore, enforce IWYU to always keep the header.

Github-Pull: bitcoin/bitcoin#36247
Rebased-From: 1aa500b6b7d8a4dc1ff374f4a033799194bc5470

e48ac92257

hebasto approved

hebasto commented at 11:36 AM on September 14, 2026: member

ACK e48ac922572940a2cb85044c06ddb59128c95188, I have reviewed the code and it looks OK.

DrahtBot removed the label CI failed on Sep 14, 2026

fanquake commented at 12:51 PM on September 14, 2026: member

ACK e48ac922572940a2cb85044c06ddb59128c95188

fanquake merged this on Sep 14, 2026

fanquake closed this on Sep 14, 2026

janb84 commented at 5:47 PM on September 15, 2026: contributor

I have issue with this commit (and v31.RC1 the tag that is based on this)

The normal build, builds normally and everything is ok (bitcoind works) With the dev_mode preset; the build succeeds but the execution of bitcoind fails

./build_dev_mode/bin/bitcoind --version
Abort trap: 6              ./build_dev_mode/bin/bitcoind --version

Tested this with both the RC tag and this commit.

MacOS 27, Aarch64

sedited commented at 7:33 AM on September 16, 2026: contributor

Tested this with both the RC tag and this commit.

Can you provide a stacktrace or a systrace or something else that might give a bit more insight into what is going on?

fanquake commented at 9:18 AM on September 16, 2026: member

but the execution of bitcoind fails

I haven't yet been able to recreate this.

janb84 commented at 3:23 PM on September 16, 2026: contributor

trace:

(lldb) b __cxa_throw
(lldb) run
frame [#1](/bitcoin-bitcoin/1/): std::__throw_out_of_range
frame [#2](/bitcoin-bitcoin/2/): std::map<wallet::WalletFlags, std::string>::at(this=size=0, ...) const
frame [#3](/bitcoin-bitcoin/3/): __cxx_global_var_init.9() at wallet.h:173:28
frame [#4](/bitcoin-bitcoin/4/): dyld4::LibSystemHelpers::callInitializer(...)

It's a specific issue with the ld64 linker used by nix on macOS. :

src/wallet/wallet.h defines two inline maps (changed in #35852 ) , and the initializer of the second one reads the first, so the order counts.

inline const std::map<WalletFlags, std::string> WALLET_FLAG_TO_STRING{ ... };

inline const std::map<std::string, WalletFlags> STRING_TO_WALLET_FLAG{
    {WALLET_FLAG_TO_STRING.at(WALLET_FLAG_AVOID_REUSE), WALLET_FLAG_AVOID_REUSE},
    ...
};

This order is preserved by clang but ld64 does not preserve this order.

Apple ld-27037.1 from the Command Line Tools is fine btw.

fanquake commented at 3:29 PM on September 16, 2026: member

Can you provide the exact steps to reproduce?

It's a specific issue with the ld64 linker used by nix on macOS. :

Do you mean lld? ld64 is the native macOS linker, which should also be doing the linking for Apple Clang. Or is Nix shipping its own different version of ld64?

willcl-ark commented at 3:34 PM on September 16, 2026: member

@janb84 I have been seeing this on my nightly jobs, e.g. https://my.cdash.org/builds/4081910 from https://my.cdash.org/index.php?project=bitcoin-core&date=2026-09-12

Where my clanker came up with a similar underlying cause:

Using LLVM tools through nix-shell, I found the wrong order in the CI executable itself:
First initializer:   construct STRING_TO_WALLET_FLAG
                       → reads WALLET_FLAG_TO_STRING → throws
Later initializers:  populate WALLET_FLAG_TO_STRING
C++ requires the opposite order for these inline variables defined together in that header. This is not simply an unspecified static-initialization order. C++ ordering rules

To identify what broke it, the next CI experiment should:

Save the wallet object files and inspect their initializer ordering.

Relink those same objects with another linker. The failing executable uses ld64-956.6.

Run each executable with -version. No functional tests are needed to reproduce a pre-main crash.

Correct object ordering but broken executable ordering points toward the linker. Wrong ordering already in the objects points toward compiler output. Relinking without recompiling separates those possibilities.

It is happening when I was using Clang 21 but wasn't happening with Clang 22. @fanquake my build was using ld: https://my.cdash.org/builds/4081910/notes#284077

janb84 commented at 3:39 PM on September 16, 2026: contributor

Can you provide the exact steps to reproduce?

Let me see if I can make something more portable, other than "install nix 26.05, use clang-wrapper, do a dev-mode build of this pr".

It's a specific issue with the ld64 linker used by nix on macOS. :

Do you mean lld? ld64 is the native macOS linker, which should also be doing the linking for Apple Clang. Or is Nix shipping its own different version of ld64?

it provides it's own Version: 956.6

So given it passes CI / guix, and it only happens in certain cases with nix-packages on macOS, I would opt to drop this for now.

sedited commented at 3:52 PM on September 16, 2026: contributor

So given it passes CI / guix, and it only happens in certain cases with nix-packages on macOS, I would opt to drop this for now.

Drop this as in do nothing? I would nevertheless open an issue for this. That mapping code is kind of funky. I wonder if there is a better way to do it.

janb84 commented at 4:01 PM on September 16, 2026: contributor

It is happening when I was using Clang 21 but wasn't happening with Clang 22.

I did a clean build with clang 22.1.8, on my machine problem persists.

So given it passes CI / guix, and it only happens in certain cases with nix-packages on macOS, I would opt to drop this for now.

Drop this as in do nothing? I would nevertheless open an issue for this. That mapping code is kind of funky. I wonder if there is a better way to do it.

As in, I see this as a nix-pkgs specific issue. But I agree that's maybe to short sighted

maflcko commented at 4:08 PM on September 16, 2026: member

@fanquake my build was using ld: https://my.cdash.org/builds/4081910/notes#284077

Is the nix shell available and do you think it would repro on Linux as well?

willcl-ark commented at 6:26 PM on September 16, 2026: member

Is the nix shell available

kind of.... it's taken from https://github.com/bitcoin-dev-tools/bix but it does a nix flake update before running. so while Bix remains pinned to flake.lock, the nightly job runs... a nightly build. But wouldn't take long to find a commit from that day and pin to it and repro.

and do you think it would repro on Linux as well?

There are several nightly builds on Linux and none of them suffer this issue. Nix Darwin is using cctools from here which includes an old version of ld64.

janb84 commented at 7:42 PM on September 16, 2026: contributor

Can you provide the exact steps to reproduce?

My clanker and I made this plan how to reproduce using apple containers;

https://gist.github.com/janb84/b91a7ffea7befb885632ff5a95247415

It is made by claude with help from me! ( tested and adopted by me) the end result is the same broken bin. Between the steps there is some clanker text I didn't feel like reading it and correcting it. Maybe it's handy maybe not. oh and apple container != docker

fanquake commented at 9:13 PM on September 16, 2026: member

Can track in #36281.