Skip to content

Stop building jsoncpp with exception catching enabled - #6852

Open
Fedr wants to merge 20 commits into
masterfrom
no-jsoncpp-exceptions
Open

Stop building jsoncpp with exception catching enabled#6852
Fedr wants to merge 20 commits into
masterfrom
no-jsoncpp-exceptions

Conversation

@Fedr

@Fedr Fedr commented Sep 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

-s NO_DISABLE_EXCEPTION_CATCHING=1 is added to CMAKE_CXX_FLAGS for the jsoncpp subdirectory only, in both thirdparty/CMakeLists.txt and the CPM stage1 copy. It buys nothing: the final Emscripten link keeps the default DISABLE_EXCEPTION_CATCHING=1, so jsoncpp's catch blocks are unreachable — __cxa_throw aborts at the throw either way. All the flag does is suppress emcc's automatic -fignore-exceptions for that one target (tools/compile.py), leaving jsoncpp with exception landing pads nothing can use.

Based on master, so this is tested against the emsdk version currently in use.

Note: an earlier revision of this PR also removed the setTempRet0 link workaround from #6850, on the theory that this flag was what made it necessary. CI disproved that — with the flag gone the wasm link still failed on variable setTempRet0 is undeclared, and an llvm-nm sweep showed that no MeshLib object and no third-party archive imports __cxa_find_matching_catch; it comes from a retained member of emsdk's own sysroot libc++/libc++abi. That workaround stays in #6850.

🤖 Generated with Claude Code

Fedr and others added 16 commits September 12, 2026 22:59
@Fedr @claude
Bump emsdk 4.0.19 -> 6.0.9
8e13262 
4.0.19 carries the syscall-proxying race emscripten fixed in #26582 and shipped
in 5.0.5: emscripten_proxy_finish signalled the proxy context's condvar after
releasing its mutex, so the waiter could return and destroy the context off its
own stack before the signal landed. Under -pthread every syscall is proxied to
the main thread, so any worker doing file I/O could lose its wakeup and hang.

The base stage moves to noble with it - emsdk images are built on noble from the
5.x line on, and binaries linking glibc 2.39 do not run on jammy - which the apt
suites follow.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
TEMPORARY: build on emsdk's stock clang
22d89fa 
clang-emsdk-6.0.9-pgo is still building in MeshInspector/toolchains, so the
download 404s. Comment it out to let this PR's CI exercise the emsdk bump now;
restore before merging or the image loses the PGO build-time win.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Build libjpeg-turbo PIC for the emsdk bump
9580d97 
Its sharedlib/ directory adds example programs that link the .so unconditionally,
and on wasm a .so is a side module, so emcc links those executables as a main
module where every object has to be PIC. 4.0.19 let it through; 6.0.9's wasm-ld
fails them with R_WASM_TABLE_INDEX_SLEB against jpeg_std_error and friends.

This script runs only from the emscripten branch of build_thirdparty.sh, so no
other platform sees the flag.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Move the PIC flag to the emscripten thirdparty options
2933962 
libjpeg-turbo was not the only one: libzip is built shared here and links
libmbedcrypto.a, whose objects are not PIC either, so 6.0.9's wasm-ld fails that
link too. The thirdparty scripts all inherit MR_CMAKE_OPTIONS, so setting
CMAKE_POSITION_INDEPENDENT_CODE once in the emscripten block covers every one of
them instead of fixing them one at a time.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Retarget the bump to 5.0.7 instead of 6.0.9
f475dc6 
6.0.9 is LLVM 24 and was turning into a toolchain migration rather than a bump:
PIC across all thirdparty, then emsdk's own non-PIC zlib port, then fmt failing
to compile because clang 24 no longer pulls in <cstdlib> transitively.

5.0.5 is where the syscall-proxying fix landed and 5.0.7 is the last of that
line, at LLVM 23. The reproducer measured 0 stalls in 24 shards on it, same as
6.0.9. 6.x stays worth doing, separately.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Give the wasm build <cstdlib> for fmt
5789fd0 
fmt 11.x calls bare malloc/free in format.h and relied on a transitive <cstdlib>
that the libc++ in emsdk 5.x no longer provides. It is an unqualified name in a
non-dependent template body, so every TU including format.h fails to parse, not
just fmt's own os.cc.

fmt fixed this properly in 12.0.0 (std::malloc plus the include), but that pin
also drags spdlog, which is a decision for another PR. -include cstdlib is two
lines, costs nothing, is confined to the emscripten path, and comes out when fmt
moves. In build_thirdparty.sh it has to sit after the flag blocks above, which
rebuild CXXFLAGS from CFLAGS - and it cannot go in CFLAGS, being C++ only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Put the fmt <cstdlib> flag where the thirdparty build reads its flags
ba70bcf 
The CXXFLAGS export did not reach that configure at all - the failing compile
line carried only flags set in thirdparty/CMakeLists.txt and not one from the
environment. Set it beside the other MR_EMSCRIPTEN flags there instead, which is
also where the -w and -pthread ones live.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Let MRStringConvert.cpp keep using wstring_convert under emsdk 5.x
2bb968d 
The file already says it means to use the deprecated API and wraps it in
MR_SUPPRESS_WARNING, but the newer libc++ attributes the diagnostic to its own
wstring_convert.h rather than to our call, so the pragma never applies and
-Werror fails the wasm build. A per-file flag reaches it; emscripten only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr
gWindowSizeInitialized
0434682
@Fedr @claude
Drop the thirdparty PIC flag: it was a 6.0.9 need, and it is a suspec…
1c14c60 
…t now

Every non-PIC link error came from 6.0.9 / LLVM 24; none has appeared on 5.0.7.
Meanwhile both apps now fail at wasm-emscripten-finalize with a binaryen parse
exception, and feeding PIC thirdparty objects into a module that is not
relocatable is the most plausible thing in this branch to produce a binary
binaryen cannot read. If the link errors come back, this goes back in.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Force setTempRet0 into the wasm module so closure can see it
fab0706 
emscripten attaches findMatchingCatch's dependency on $setTempRet0 only under
!DISABLE_EXCEPTION_CATCHING, while the stub that actually calls setTempRet0 is
the DISABLE_EXCEPTION_CATCHING one - so with catching off, as we build, nothing
emits the symbol and --closure=1 fails with JSC_UNDEFINED_VARIABLE.

Worth reporting upstream; until then DEFAULT_LIBRARY_FUNCS_TO_INCLUDE pulls it in.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Test whether the app builds still need the fmt <cstdlib> flag
63d4e99 
The thirdparty copy is proven - fmt's own os.cc will not compile without it. This
one covers MeshLib and MeshInspector sources, which reach format.h through
MRPch -> spdlog, and has never been tested on its own. If the app builds go red,
it goes straight back.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Switch back to the PGO clang, now that 5.0.7 has one
aff334e 
clang-emsdk-5.0.7-pgo published (clang 23.0.0git, both arches). Restores the
toolchain swap this image has always done; the stock ThinLTO-only clang was only
ever a stand-in while the toolchain built.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr
Merge branch 'master' into bump-emsdk-6.0.9
53faa20
@Fedr
comment dropped
d05435e
@Fedr @claude
Stop building jsoncpp with exception catching enabled
e121bc6 
The flag only changed jsoncpp's codegen: the final link has catching
disabled, so its catch blocks were dead and __cxa_throw aborted anyway.
It did leave jsoncpp with landing pads, which is what dragged in
findMatchingCatch and forced the setTempRet0 workaround.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr
Fedr changed the base branch from bump-emsdk-6.0.9 to master September 13, 2026 17:15
@Fedr Fedr closed this Sep 13, 2026
@Fedr Fedr reopened this Sep 13, 2026
Fedr and others added 4 commits September 13, 2026 20:53
@Fedr @claude
TEMPORARY: find which objects carry exception landing pads
5222685 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
TEMPORARY: widen the landing-pad probe to the sysroot
cd1e741 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Revert the emsdk bump and the probe: test on master's emsdk
0110e38 
Keeps only the jsoncpp change; the setTempRet0 workaround this PR was
meant to eliminate turned out to be needed for an unrelated reason
(sysroot libc++ carries the landing pads), so the bump is not involved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr @claude
Drop the fmt cstdlib shim: it belongs to the emsdk bump, not here
d8a3d18 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Fedr Fedr added the full-ci run all steps label Sep 14, 2026
@Fedr
Fedr requested a review from Grantim September 14, 2026 09:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Grantim Grantim Awaiting requested review from Grantim

Assignees

No one assigned

Labels

disable-build-linux-vcpkg disable-build-macos disable-build-ubuntu-arm64 disable-build-ubuntu-x64 disable-build-windows full-ci run all steps

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@Fedr