Build issue with cmake 4.4 on MacOS: FindSQLite3 re-ordering headers import: "unknown type name '__uint32_t'" #35981

Recently upgraded cmake to 4.4 and encountered a build issue on master. It appears to be caused by a change in cmake to how it finds SQLite3:

https://cmake.org/cmake/help/latest/release/4.3.html#modules

The FindSQLite3 module now provides imported targets with the SQLite3:: prefix.

Despite sqlite being installed via homebrew, cmake finds the MacOS.sdk version, and imports system headers before llvm or clang headers, causing the compiler to forget what a 32 bit integer is 🤷

-- Found SQLite3: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libsqlite3.tbd (found suitable version "3.43.2", minimum required is "3.7.17")

The build completes successfully by adding the flag -DSQLite3_ROOT="$(brew --prefix sqlite)"

-- Found SQLite3: /opt/homebrew/opt/sqlite/lib/libsqlite3.dylib (found suitable version "3.53.2", minimum required is "3.7.17")

Summary:

macos 14.8.2 Clang 22.1.7 Cmake 4.4.2 bitcoin master at a8b582ec1d25e012731fcca122552b59f8967610

Relevant environment variables:

MACOSX_DEPLOYMENT_TARGET=14.5
CXX=/opt/homebrew/opt/llvm/bin/clang++
LDFLAGS=-L/opt/homebrew/opt/llvm/lib
CPPFLAGS=-I/opt/homebrew/opt/llvm/include
HOMEBREW_CELLAR=/opt/homebrew/Cellar
HOMEBREW_REPOSITORY=/opt/homebrew
CC=/opt/homebrew/opt/llvm/bin/clang
CXX=/opt/homebrew/opt/llvm/bin/clang++

Reproducable:

git clean -xdf
ccache -c
rm -rf ~/Library/Caches/ccache/
cmake -B build -DWITH_ZMQ=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build -j 1

First build error of many:

[  3%] Building CXX object src/wallet/CMakeFiles/bitcoin_wallet.dir/coincontrol.cpp.o
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/wallet/coincontrol.cpp:5:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/wallet/coincontrol.h:8:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/outputtype.h:9:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/addresstype.h:9:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/pubkey.h:10:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/hash.h:10:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/crypto/common.h:8:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/compat/endian.h:8:
In file included from /Users/matthewzipkin/Desktop/work/bitcoin/src/compat/byteswap.h:8:
In file included from /opt/homebrew/Cellar/llvm/22.1.7/bin/../include/c++/v1/cstdint:149:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdint.h:52:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:33:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/machine/_types.h:34:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/arm/_types.h:16:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_ptrdiff_t.h:41:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stddef.h:64:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'
   43 | typedef __uint32_t      __darwin_wctype_t;
      |         ^

GPT pointed this out as the smoking gun:

--> cmake --build build --verbose -j1 2>&1 | grep -m1 'clang++' cd /Users/matthewzipkin/Desktop/work/bitcoin/build/src/wallet && /opt/homebrew/bin/ccache /opt/homebrew/opt/llvm/bin/clang++ -DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -I/Users/matthewzipkin/Desktop/work/bitcoin/build/src -I/Users/matthewzipkin/Desktop/work/bitcoin/src -I/Users/matthewzipkin/Desktop/work/bitcoin/src/univalue/include -isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -isystem /opt/homebrew/Cellar/boost/1.87.0/include -O2 -g -std=c++20 -arch arm64 -mmacosx-version-min=14.5 -fPIC -fmacro-prefix-map=/Users/matthewzipkin/Desktop/work/bitcoin/src=. -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -Wstack-protector -fstack-protector-all -mbranch-protection=bti -Wall -Wextra -Wgnu -Wcovered-switch-default -Wformat -Wformat-security -Wvla -Wshadow-field -Wthread-safety -Wthread-safety-pointer -Wloop-analysis -Wredundant-decls -Wunused-member-function -Wdate-time -Wconditional-uninitialized -Woverloaded-virtual -Wsuggest-override -Wimplicit-fallthrough -Wunreachable-code -Wdocumentation -Wself-assign -Wundef -Wno-unused-parameter -MD -MT src/wallet/CMakeFiles/bitcoin_wallet.dir/coincontrol.cpp.o -MF CMakeFiles/bitcoin_wallet.dir/coincontrol.cpp.o.d -o CMakeFiles/bitcoin_wallet.dir/coincontrol.cpp.o -c /Users/matthewzipkin/Desktop/work/bitcoin/src/wallet/coincontrol.cpp

... because it's adding -isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include too early

I haven't dug into the issue itself yet, but I wanted to leave a few quick notes.

Recently upgraded cmake to 4.4 and encountered a build issue on master. It appears to be caused by a change in cmake to how it finds SQLite3:

https://cmake.org/cmake/help/latest/release/4.3.html#modules

The FindSQLite3 module now provides imported targets with the SQLite3:: prefix.

This CMake change was already addressed in #34848.

Despite sqlite being installed via homebrew, cmake finds the MacOS.sdk version, and imports system headers before llvm or clang headers, causing the compiler to forget what a 32 bit integer is 🤷

-- Found SQLite3: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libsqlite3.tbd (found suitable version "3.43.2", minimum required is "3.7.17")

The build completes successfully by adding the flag -DSQLite3_ROOT="$(brew --prefix sqlite)"

-- Found SQLite3: /opt/homebrew/opt/sqlite/lib/libsqlite3.dylib (found suitable version "3.53.2", minimum required is "3.7.17")

Simply installing another instance of a dependency via Homebrew doesn't automatically tell CMake to prefer it over the system version. Explicitly passing -DSQLite3_ROOT is the correct way to point CMake to the Homebrew installation.

Relevant environment variables:

MACOSX_DEPLOYMENT_TARGET=14.5
CXX=/opt/homebrew/opt/llvm/bin/clang++
LDFLAGS=-L/opt/homebrew/opt/llvm/lib
CPPFLAGS=-I/opt/homebrew/opt/llvm/include
HOMEBREW_CELLAR=/opt/homebrew/Cellar
HOMEBREW_REPOSITORY=/opt/homebrew
CC=/opt/homebrew/opt/llvm/bin/clang
CXX=/opt/homebrew/opt/llvm/bin/clang++

Just to clarify, does the issue occur when you use the default toolchan with all toolchain-specific variables unset?

toolchain-specific variables unset?

First error: compiler falls back to AppleClang 16.0.0.16000026

CMake Error at cmake/module/CheckCXXFeatures.cmake:32 (message):
  Compiler lacks Class Template Argument Deduction (CTAD) for aggregates.

  This C++ feature is required for src/util/overloaded.h.

Putting the compiler aliases back but leaving out the FLAGS, still get the same build error

toolchain-specific variables unset?

First error: compiler falls back to AppleClang 16.0.0.16000026

CMake Error at cmake/module/CheckCXXFeatures.cmake:32 (message):
  Compiler lacks Class Template Argument Deduction (CTAD) for aggregates.

  This C++ feature is required for src/util/overloaded.h.

~Not directly related to the issue, just curious if your system is older than Sequoia and upgrading of Xcode is not an option?~

I've just read it in the OP: macos 14.8.2

Since I don't have direct access to a macOS 14 machine, I tried reproducing the issue using the macos-14 GHA image.

So far, I haven't been able to reproduce even the base scenario using the default toolchain.

My build succeeded, while the configure error was reported here. @pinheadmz Mind sharing the relevant part of your CMakeFiles/CMakeConfigureLog.yaml to help us figure out the substantial differences between our build environments?

First error: compiler falls back to AppleClang 16.0.0.16000026

Hmm, interesting. The latest XCode CLT 16.2 for your macos-14 should work fine. Recall we have a CI task for this: https://github.com/bitcoin/bitcoin/actions/runs/31889658030/job/95023943893#step:4:14 says Apple clang version 16.0.0 (clang-1600.0.26.6)

~Not directly related to the issue, just curious if your system is older than Sequoia and upgrading of Xcode is not an option?~

I've just read it in the OP: macos 14.8.2

Just sliding in on this off-topic branch: Do you think your hardware supports an upgrade to macos 15? I am wondering when we want to switch to C++23, and also GHA will likely soon deprecated macos-14 images, so continuing support for macos-14 may be difficult.

I don't want to suggest to drop support too early, if it affects a bunch of devs or users, but my recommendation for those on older macs would be to use nix/brew (https://github.com/bitcoin/bitcoin/pull/33489#issuecomment-3388922270). I guess you are already using a third-party compiler from nix or brew, so bumping the minimum required Xcode CLT wouldn't affect you anyway?

I just went ahead and upgraded to Tahoe (macos 26.6.1), upgraded xcode and all its tools, wiped all my env vars and STILL got the CTAD error with the apple-only tool chain. the thing that worked was (thanks to gpt):

sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer

It was previously pointing at /Library/Developer/CommandLineTools

GPT says "That's a legitimate Apple toolchain, but it is a smaller toolchain than full Xcode. It provides things like clang, git, make, headers, and macOS SDK components, but it is not a full Xcode installation. Some commands—most notably xcodebuild—require full Xcode to be selected. Apple explicitly distinguishes the two configurations."

So locally now I am building Bitcoin just fine with the apple chain. I think on the older system I installed components from brew maybe for fuzzing or for the sanitizers, maybe even for another C project that wouldn't build with my bitcoin setup. Hebasto is saying that macos 14 clang works, so I am going to close this issue as user misconfiguration.

I don't want to suggest to drop support too early

macos 14 is the oldest version still supported by Apple, It will probably EOL soon and then dropping it is justified.