From 34f95a3699ef663f2b4d7a05b351ab38155f57a6 Mon Sep 17 00:00:00 2001 From: Fedor Chelnokov Date: Fri, 22 May 2026 12:36:42 +0300 Subject: [PATCH 1/2] Apply libc++ __init_primary_exception override under AppleClang too The clang.hpp workaround for https://github.com/llvm/llvm-project/issues/86077 defines `_LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION 0` to keep inline libc++ codepaths from emitting references to `__from_native_exception_pointer`. That symbol was added to libc++ in LLVM 18 / macOS 14 SDK and is absent from /usr/lib/libc++.1.dylib on earlier macOS, so any dylib that references it fails dyld on macos-12 or macos-13 hosts. The original code guarded the override two ways and both excluded AppleClang: - clang.hpp: `!defined(__apple_build_version__)` skipped the entire #undef/#define when the consumer compiles with AppleClang (the macro is defined only by AppleClang). - CMakeLists: `CMAKE_CXX_COMPILER_ID STREQUAL "Clang"` matched only upstream LLVM clang -- AppleClang's compiler id is `"AppleClang"`, so the target_precompile_headers call that injects clang.hpp into fastmcpp_core's own translation units never ran on AppleClang. Apple's libc++ derives from upstream and honors the same macro, so the override is meaningful under AppleClang. On older AppleClang whose libc++ doesn't define the macro at all, the #undef/#define is a harmless no-op. Both gates have to be lifted in tandem: the consumer-side fix in clang.hpp is moot if fastmcpp_core itself is still compiled without the override, since `fastmcpp_core` is a STATIC library and its .o files get linked into downstream dylibs at the consumer site. Concrete downstream symptom (MeshInspector/MeshLib PR #6138, x64 .pkg built with AppleClang on macos-15-intel, installed on a Mac Pro 2013 running macOS 12): dyld: Symbol not found: __ZNSt13exception_ptr31__from_native_exception_pointerEPv Referenced from: .../libMRMcp.dylib Expected in: /usr/lib/libc++.1.dylib --- CMakeLists.txt | 2 +- include/fastmcpp/clang.hpp | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index dbfa837..90958dc 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -72,7 +72,7 @@ if(MSVC) endif() # inject work-around for Clang libc++ and older Xcode versions' compatibility -if(APPLE AND CMAKE_CXX_COMPILER_ID STREQUAL "Clang") +if(APPLE AND CMAKE_CXX_COMPILER_ID MATCHES "^(Apple)?Clang$") target_precompile_headers(fastmcpp_core PRIVATE $<$:${CMAKE_CURRENT_SOURCE_DIR}/include/fastmcpp/clang.hpp> diff --git a/include/fastmcpp/clang.hpp b/include/fastmcpp/clang.hpp index 9596292..a6521c5 100644 --- a/include/fastmcpp/clang.hpp +++ b/include/fastmcpp/clang.hpp @@ -2,7 +2,7 @@ // Work around Clang quirk: https://github.com/llvm/llvm-project/issues/86077 // This must be included before `` to work correctly, so effectively before any standard library headers. -#if defined( __APPLE__ ) && defined( __clang__ ) && !defined( __apple_build_version__ ) +#if defined( __APPLE__ ) && defined( __clang__ ) #include #undef _LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION #define _LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION 0 From f0a3076208dc66271e71f1ba3d3c95227cbb59dc Mon Sep 17 00:00:00 2001 From: Fedor Chelnokov Date: Fri, 22 May 2026 12:49:54 +0300 Subject: [PATCH 2/2] CMakeLists: spell out two STREQUAL checks instead of a MATCHES regex Review nit -- two explicit equality checks are easier to read than the regex, and the gate has only two compiler ids to cover. --- CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 90958dc..f9df82a 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -72,7 +72,7 @@ if(MSVC) endif() # inject work-around for Clang libc++ and older Xcode versions' compatibility -if(APPLE AND CMAKE_CXX_COMPILER_ID MATCHES "^(Apple)?Clang$") +if(APPLE AND (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")) target_precompile_headers(fastmcpp_core PRIVATE $<$:${CMAKE_CURRENT_SOURCE_DIR}/include/fastmcpp/clang.hpp>