From 2c208008c017003324fe90a10229897a38b30f8c Mon Sep 17 00:00:00 2001 From: Thiago Vinhas Date: Wed, 13 May 2026 15:19:45 -0500 Subject: [PATCH 1/2] fix(fmt): set FMT_USE_CONSTEVAL=0 in fmt.podspec for Xcode 26.x compatibility --- .../third-party-podspecs/fmt.podspec | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/packages/react-native/third-party-podspecs/fmt.podspec b/packages/react-native/third-party-podspecs/fmt.podspec index 2f38990e226c..571c5d239fd4 100644 --- a/packages/react-native/third-party-podspecs/fmt.podspec +++ b/packages/react-native/third-party-podspecs/fmt.podspec @@ -19,7 +19,21 @@ Pod::Spec.new do |spec| } spec.pod_target_xcconfig = { "CLANG_CXX_LANGUAGE_STANDARD" => rct_cxx_language_standard(), - "GCC_WARN_INHIBIT_ALL_WARNINGS" => "YES" # Disable warnings because we don't control this library + "GCC_WARN_INHIBIT_ALL_WARNINGS" => "YES", # Disable warnings because we don't control this library + # [macOS] Xcode 26.x ships a stricter consteval evaluator than + # fmt 11.0.2's `FMT_STRING` macro expects, breaking the compile + # of `Pods/fmt/src/format.cc` with "call to consteval function is + # not a constant expression" at `format-inl.h:59, 60, 1387, 1391, + # 1394, ...`. fmt's own internal logic already gates consteval off + # for compilers it considers broken (see `base.h:113-132` — + # Apple clang <14, MSVC VS2019 <16.10, etc.); Xcode 26.x exposes a + # new failure mode that hasn't been added to that list yet, so we + # opt out of consteval here. The constexpr fallback fmt provides + # is fully functional — only the compile-time format-string check + # is sacrificed. Long-term fix is to bump fmt to 11.1+, where the + # underlying issue is addressed upstream; until then this is the + # minimal, reversible workaround. + "GCC_PREPROCESSOR_DEFINITIONS" => "$(inherited) FMT_USE_CONSTEVAL=0" } spec.platforms = min_supported_versions spec.libraries = "c++" From 3c6ea99a3d2f8e740e65b4f3d0d691de4013d5d3 Mon Sep 17 00:00:00 2001 From: Thiago Vinhas Date: Wed, 13 May 2026 18:24:46 -0500 Subject: [PATCH 2/2] fix(fmt): patch base.h via prepare_command instead of xcconfig -D The xcconfig GCC_PREPROCESSOR_DEFINITIONS approach doesn't actually work: fmt's base.h:113-132 chain has no #ifndef guard and unconditionally redefines FMT_USE_CONSTEVAL=1 on any compiler that sets __cpp_consteval. Patching base.h via prepare_command is the only path that survives the preprocessor. Validated locally on Xcode 26.5: pod install + xcodebuild succeed against both packages/rn-tester and microsoft/react-native-test-app's example-macos. --- .../third-party-podspecs/fmt.podspec | 43 ++++++++++++------- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/packages/react-native/third-party-podspecs/fmt.podspec b/packages/react-native/third-party-podspecs/fmt.podspec index 571c5d239fd4..058a473820fd 100644 --- a/packages/react-native/third-party-podspecs/fmt.podspec +++ b/packages/react-native/third-party-podspecs/fmt.podspec @@ -17,23 +17,36 @@ Pod::Spec.new do |spec| :git => fmt_git_url, :tag => "11.0.2" } + # Patch fmt's existing "Apple clang < 14 broken" gate at + # `include/fmt/base.h:122` to catch ALL Apple clang versions. fmt 11.0.2's + # consteval `basic_format_string` constructor is rejected by Xcode 26.x's + # stricter constexpr evaluator, breaking the compile of `Pods/fmt/src/format.cc` + # at `format-inl.h:59`, `60`, `1387`, `1391`, `1394`, etc. with: + # + # error: call to consteval function 'fmt::basic_format_string<...>' + # is not a constant expression + # + # fmt already disables consteval for compilers it considers broken + # (Apple clang < 14, MSVC VS2019 < 16.10 etc. — see `base.h:113-132`) by + # forcing the `FMT_USE_CONSTEVAL=0` branch of its config chain. Widening + # the existing Apple-clang branch to drop the `< 14000029L` upper bound + # adds Xcode 26.x to that broken-list and falls back to fmt's constexpr + # path, which compiles cleanly. Notes: + # + # - An xcconfig `GCC_PREPROCESSOR_DEFINITIONS = FMT_USE_CONSTEVAL=0` + # alone does NOT work: fmt's chain in `base.h:113-132` has no + # `#ifndef FMT_USE_CONSTEVAL` guard and unconditionally redefines the + # macro to `1` on any compiler that sets `__cpp_consteval`. Patching + # the source is the only path that survives the preprocessor. + # - Long-term fix is a fmt 11.1+ bump (fmt's own upstream addressed the + # stricter-eval interaction there). This `sed` is the minimal, + # reversible workaround until that lands. + spec.prepare_command = <<-CMD + /usr/bin/sed -i.bak 's|defined(__apple_build_version__) && __apple_build_version__ < 14000029L|defined(__apple_build_version__)|' include/fmt/base.h + CMD spec.pod_target_xcconfig = { "CLANG_CXX_LANGUAGE_STANDARD" => rct_cxx_language_standard(), - "GCC_WARN_INHIBIT_ALL_WARNINGS" => "YES", # Disable warnings because we don't control this library - # [macOS] Xcode 26.x ships a stricter consteval evaluator than - # fmt 11.0.2's `FMT_STRING` macro expects, breaking the compile - # of `Pods/fmt/src/format.cc` with "call to consteval function is - # not a constant expression" at `format-inl.h:59, 60, 1387, 1391, - # 1394, ...`. fmt's own internal logic already gates consteval off - # for compilers it considers broken (see `base.h:113-132` — - # Apple clang <14, MSVC VS2019 <16.10, etc.); Xcode 26.x exposes a - # new failure mode that hasn't been added to that list yet, so we - # opt out of consteval here. The constexpr fallback fmt provides - # is fully functional — only the compile-time format-string check - # is sacrificed. Long-term fix is to bump fmt to 11.1+, where the - # underlying issue is addressed upstream; until then this is the - # minimal, reversible workaround. - "GCC_PREPROCESSOR_DEFINITIONS" => "$(inherited) FMT_USE_CONSTEVAL=0" + "GCC_WARN_INHIBIT_ALL_WARNINGS" => "YES" # Disable warnings because we don't control this library } spec.platforms = min_supported_versions spec.libraries = "c++"