depends: use -Xclang -fno-cxx-modules in macOS cross build
What the developer wrote
Authored by fanquake
depends: use -Xclang -fno-cxx-modules in macOS cross build
Newer versions of the macOS SDK, have introduced code like:
```cpp
if defined(__has_feature) && __has_feature(modules)
define USE_CLANG_TYPES 1
else
define USE_CLANG_TYPES 0
endif
if USE_CLANG_TYPES
include <sys/_types/_ptrdiff_t.h>
include <sys/_types/_size_t.h>
include <sys/_types/_va_list.h>
include <sys/_types/_wchar_t.h>
endif
```
which is currently causing compile failures due to undeclared types,
which manifest when C++ modules are enabled. Note that the usage of
"modules" in LLVM is can be a bit ambiguous, see:
https://github.com/llvm/llvm-project/issues/55891.
For now, explcitly disable cxx modules using `-fno-cxx-modules`. This
resolves the include/compilation issues.
Related discussion:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
https://github.com/llvm/llvm-project/pull/150349
https://github.com/llvm/llvm-project/issues/57432
What changed, and why it matters
This is a build-system fix for compiling Bitcoin Core for macOS using newer Apple SDKs. It adds a compiler flag that turns off a Clang C++ feature called 'modules,' which was causing compile failures because the SDK uses that feature to decide whether to include some standard type definitions. There is no indication this is a security vulnerability or that it could be exploited by an attacker.
No security action required. Treat as a normal build-fix commit. Reviewers may verify that -fno-cxx-modules does not interact negatively with other toolchain flags or reproducibility goals, but the change appears benign.
Security signals we found
No security-relevant signals present in commit message or diff
Change is purely a build-system/compiler-flag workaround
No mention of vulnerabilities, exploits, memory safety, cryptography, or attacker-controlled input
Evidence from the diff
The commit modifies depends/hosts/darwin.mk to append -Xclang -fno-cxx-modules to darwin_CXXFLAGS during cross-compilation for macOS. Newer macOS SDKs gate inclusion of headers such as sys/_types/_ptrdiff_t.h, _size_t.h, _va_list.h, and _wchar_t.h behind __has_feature(modules) via USE_CLANG_TYPES. When Clang’s C++ modules support is active, these definitions are not being made available as expected, causing undeclared-type compilation failures. The patch explicitly disables C++ modules because the project does not use them. This is a build-compatibility workaround, not a runtime code change.
Changed components
depends/hosts/darwin.mkmacOS cross-compilation toolchain flagsClang C++ module handling for Darwin targetInspect captured patch +7 / −1
diff --git a/depends/hosts/darwin.mk b/depends/hosts/darwin.mk
index d33b681b..6f38a15b 100644
--- a/depends/hosts/darwin.mk
+++ b/depends/hosts/darwin.mk
@@ -50,6 +50,12 @@ darwin_STRIP=$(shell $(SHELL) $(.SHELLFLAGS) "command -v llvm-strip")
#
# Disable adhoc codesigning (for now) when using LLVM tooling, to avoid
# non-determinism issues with the Identifier field.
+#
+# -Xclang -fno-cxx-modules
+#
+# Disable C++ modules. We don't use these, and modules cause definition issues
+# in the SDK, where __has_feature(modules) is used to define USE_CLANG_TYPES,
+# which is in turn used as an include guard.
darwin_CC=$(clang_prog) --target=$(host) \
-isysroot$(OSX_SDK) -nostdlibinc \
@@ -61,7 +67,7 @@ darwin_CXX=$(clangxx_prog) --target=$(host) \
-iwithsysroot/usr/include -iframeworkwithsysroot/System/Library/Frameworks
darwin_CFLAGS=-mmacos-version-min=$(OSX_MIN_VERSION)
-darwin_CXXFLAGS=-mmacos-version-min=$(OSX_MIN_VERSION)
+darwin_CXXFLAGS=-mmacos-version-min=$(OSX_MIN_VERSION) -Xclang -fno-cxx-modules
darwin_LDFLAGS=-Wl,-platform_version,macos,$(OSX_MIN_VERSION),$(OSX_SDK_VERSION)
ifneq ($(build_os),darwin)
Why this scored 19/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.