clang.hpp + CMakeLists: apply libc++ workaround under AppleClang too#2
Merged
Conversation
Fedr
added a commit
to MeshInspector/MeshLib
that referenced
this pull request
May 21, 2026
fastmcpp's clang.hpp guarded the
`_LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION 0` override with
`!defined(__apple_build_version__)`, so the workaround only fired under
upstream LLVM clang (brew-llvm18) and not under AppleClang. The x64 .pkg
is built with AppleClang on macos-15-intel; its libMRMcp.dylib therefore
referenced __from_native_exception_pointer, which is absent from
/usr/lib/libc++.1.dylib on Monterey (macos-x64-build / Mac Pro 2013):
dyld: Symbol not found: __ZNSt13exception_ptr31__from_native_exception_pointerEPv
Referenced from: libMRMcp.dylib
Expected in: /usr/lib/libc++.1.dylib
The bumped commit (MeshInspector/fastmcpp#2) drops the
__apple_build_version__ guard so the override also applies under
AppleClang, keeping the helper out of libMRMcp.dylib and restoring
.pkg compatibility with the 12.7 deployment target the rest of the
build already targets.
Fedr
changed the title
The clang.hpp workaround for llvm/llvm-project#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
Fedr
force-pushed
the
apply-libcpp-workaround-to-appleclang
branch
from
ecfe6be to
34f95a3
Compare
oitel
approved these changes
May 22, 2026
|
|
||
| # 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$") |
There was a problem hiding this comment.
Please make it more readable by replacing MATCHES with two STREQUAL's.
Review nit -- two explicit equality checks are easier to read than the regex, and the gate has only two compiler ids to cover.
Grantim
approved these changes
May 22, 2026
adalisk-emikhaylov
approved these changes
May 22, 2026
Fedr
added a commit
to MeshInspector/MeshLib
that referenced
this pull request
May 22, 2026
Repoint thirdparty/fastmcpp from the now-orphaned PR branch tip ecfe6be to the squash-merge commit c5271bc on fastmcpp's main branch (MeshInspector/fastmcpp#2). Same source content, but the commit is now reachable from main and survives any future garbage collection of the deleted branch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The clang.hpp workaround for llvm/llvm-project#86077 defines
_LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION 0to 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.dylibon earlier macOS, so any dylib that references it fails dyld on macOS 12 or 13 hosts.The original code guarded the override two ways and both excluded AppleClang:
include/fastmcpp/clang.hpp!defined(__apple_build_version__)#undef/#defineblock was skipped when the consumer compiles with AppleClang —__apple_build_version__is defined only by AppleClang.CMakeLists.txtCMAKE_CXX_COMPILER_ID STREQUAL "Clang"target_precompile_headerscall that injectsclang.hppintofastmcpp_core's own translation units never ran on AppleClang — AppleClang's compiler id is"AppleClang".Both gates have to be lifted in tandem: the consumer-side fix in
clang.hppis moot iffastmcpp_coreitself is still compiled without the override, sincefastmcpp_coreis aSTATIClibrary and its.ofiles end up linked into downstream dylibs.Apple's libc++ derives from upstream LLVM 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/#definepair is a harmless no-op.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:libMRMcp.dylibis a MeshLib library that statically linksfastmcpp_core. With this PR applied (consumer side via submodule bump), the reference is no longer emitted under AppleClang and the .pkg loads cleanly on macOS 12/13 hosts.Test plan
thirdparty/fastmcpppointed at this PR's commit seestest-distribution / macos-test (x64, macos-x64-build, *x64.pkg)reach "Run MeshViewer" without a__from_native_exception_pointerdyld abort.