fix: emscripten-wasm32 build fixes for RoboStack/ros-rolling (Asyncify, not real pthreads)

[Tobias-Fischer]

Update: pthreads reverted, replaced with Asyncify

Everything below this section describes the branch's original approach
(real pthreads, USE_PTHREADS=1) — since superseded. Real pthreads
requires WebAssembly --shared-memory, which is viral across every
dlopen'd module and deadlocks completely inside single-thread hosts:
confirmed by direct reproduction, a pthreads-enabled rclpy build loaded
into JupyterLite's xeus-python kernel (itself not pthreads-enabled
upstream) never responds again once it blocks.

Replaced with Asyncify: vinca/templates/build_ament_cmake.sh.in now
sets -sASYNCIFY globally instead of USE_PTHREADS=1, for every
emscripten-wasm32 ament_cmake build. This lets the one genuinely
blocking call in the stack (rmw_zenoh_pico's rmw_wait, via
zenoh-pico's transport read) cooperatively yield instead of requiring a
real OS thread — see RoboStack/ros-rolling#46 for the rmw_zenoh_pico-side
changes that actually use this. A second small fix was needed alongside
it: the emscripten-forge toolchain's own activation script injects
-fwasm-exceptions into every em++/emcc call via EMCC_CFLAGS, which
crashes binaryen's Asyncify pass outright on any object using wasm
exception-handling instructions — EMCC_CFLAGS now gets overridden to
drop that flag while keeping the toolchain's own base flags.

This removes the shared-memory requirement from the whole closure, which
is also what was blocking rclpy from working inside JupyterLite in the
first place — xeus/xeus-python never need to touch pthreads at all.
The CMAKE_SHARED_MODULE_* / pinning_overrides / VINCA_EMSCRIPTEN_*
fixes described below are all still in effect and unrelated to this
pivot.

Summary (original, pthreads-based)

Flips USE_PTHREADS 0→1 (compile and link) for every emscripten-wasm32 ament_cmake build in build_ament_cmake.sh.in, plus several smaller emscripten-target fixes needed to get there and to support a second, independent emscripten-wasm32 pipeline (ROS 2 rolling + rmw_zenoh_pico, as opposed to the original ROS 2 Humble + rmw_wasm_cpp one). All changes are confined to the if [[ $target_platform =~ emscripten.* ]] branch of the template (or are purely additive env-var opt-ins) — no effect on any other platform or on emscripten builds that don't set the new env vars.

Built and validated against three full emscripten-wasm32 ROS 2 builds:

• ~104-package ROS 2 Humble build with a custom rmw_wasm_cpp, running a real rclcpp talker/listener continuously in the browser.
• ~230-package ROS 2 rolling build with rmw_zenoh_pico, running a real rclc talker in the browser that publishes to a native zenohd router over WebSocket, verified end-to-end by an independent native process receiving the message.
• The same rolling + rmw_zenoh_pico build running a real rclpy talker (CPython built with --enable-wasm-pthreads) in the browser, also verified end-to-end against a native subscriber — this is what surfaced the CMAKE_SHARED_MODULE_* gap below.

Why real pthreads (superseded, see "Update" above)

Without real threads, libc++'s condition_variable timed-wait (used by rclcpp's executor and the RMW wait-set machinery) never wakes up on its own — there is no OS thread to run a genuine blocking wait, so a synchronous wait just blocks the single JS thread forever with no way for wall-clock time to advance underneath it. In practice this meant any rclcpp::spin()-based program executed its first callback and then hung permanently. USE_PTHREADS=1 has to be set at both compile and link time for every translation unit (not just the final link) — it bakes in the wasm atomics/bulk-memory features wasm-ld requires when producing shared memory. This is applied globally via add_compile_options() in the generated CMAKE_PROJECT_INCLUDE file, so every package in the tree gets it consistently (mixing a pthread-enabled module with a non-pthread one is a hard ABI-level mismatch — a wasm module's shared-vs-non-shared linear memory is fixed at compile+link time).

The other commits

• Removes the -s DEMANGLE_SUPPORT=1 emcc flag, which emscripten 4.0.9 (the SDK version currently published as emscripten_emscripten-wasm32) rejects outright ("No longer supported"), breaking every emscripten-wasm32 ament_cmake build past the first one or two.
• _overlay() now converts v1 if/then/else selectors in pinning_overrides values into the legacy # [selector] comment form, since rattler-build's variant loader treats the raw if/then mapping as an opaque literal rather than evaluating it.
• Makes the default RMW_IMPLEMENTATION for emscripten builds configurable via VINCA_EMSCRIPTEN_RMW_IMPLEMENTATION (falls back to the existing rmw_wasm_cpp default), so other emscripten-wasm32 pipelines can select their own RMW (e.g. rmw_zenoh_pico) without forking this template.
• Makes STATIC_ROSIDL_TYPESUPPORT_C/_CPP configurable the same way via VINCA_EMSCRIPTEN_STATIC_TYPESUPPORT_C/_CPP (falls back to the existing rosidl_typesupport_introspection_c/_cpp default). A micro-ROS-lineage RMW like rmw_zenoh_pico requires messages' typesupport dispatch table to register rosidl_typesupport_microxrcedds_c/_cpp specifically — the previous hardcoded default left that dispatch table with no matching entry, so rcl_publisher_init failed with "Type support not from this implementation" for every message.
• Also sets CMAKE_SHARED_MODULE_CREATE_C_FLAGS/CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS, alongside the existing CMAKE_SHARED_LIBRARY_CREATE_*_FLAGS. CMake's MODULE library type (what pybind11_add_module() uses for every Python C extension — rclpy's own _rclpy_pybind11, and every message package's rosidl_generator_py typesupport accessor) is a distinct target type from SHARED and reads its own set of link-flag variables. Setting only the SHARED ones left every MODULE-type .so linked without USE_PTHREADS=1 — its object files were compiled with atomics support fine (add_compile_options applies globally regardless of target type), but the final linked module came out non-shared-memory, which fails to load next to the rest of a pthreads build with a "mismatch in shared state of memory" error. Invisible until something in the tree actually used pybind11_add_module() — the rclc/C-only pipelines never hit it.
• Stops pre-finding the VINCA_EMSCRIPTEN_STATIC_TYPESUPPORT_C/_CPP override for a package that calls rosidl_generate_interfaces() itself (i.e. defines its own messages/services/actions). Pre-finding it via CMAKE_PROJECT_INCLUDE was needed so a consumer package's Export.cmake (referencing rosidl_typesupport_microxrcedds_c(pp)::...) doesn't fail with "a find_package call is missing for an IMPORTED target" — but for a message-generating package, it has a side effect: it makes the override "already a target" before that package's own typesupport discovery runs, which — confirmed by inspecting the built package's own ament_cmake_export_targets-extras.cmake — bumps its typesupport entry to the front of its own _exported_targets list, ahead of the generator target its own Export.cmake requires (INTERFACE_LINK_LIBRARIES references <pkg>::<pkg>__rosidl_generator_c(pp)). Every downstream find_package(<that package>) then fails with "referenced, but are missing: <pkg>::<pkg>__rosidl_generator_c(pp)", reproducible regardless of whether the C or C++ (or both) override is set. Without any pre-find, rosidl_generate_interfaces() still discovers the same override backend on its own (via STATIC_ROSIDL_TYPESUPPORT_C/_CPP, already set unconditionally), so skipping the pre-find for these packages loses nothing for their own typesupport selection. Found and fixed while re-verifying Add emscripten-wasm32 support with rmw_zenoh_pico ros-rolling#46 from a genuinely clean output/ directory — it had been masked until then because every message package already built (with an earlier, non-pre-finding vinca commit) predated this pre-find fix.

Testing

Re-verified end-to-end from a genuinely clean output/ directory (not just incrementally, on top of already-built packages): full ~230-recipe emscripten-wasm32 closure for rolling + rmw_zenoh_pico builds green, both a real rclc and a real rclpy talker running in the browser, each independently confirmed delivering messages via a native zenohd router's own REST API (not just reading the browser's own console).

Companion changes:

• RoboStack/ros-humble-emscripten (the original rmw_wasm_cpp pipeline this PR was built for).
• Add emscripten-wasm32 support with rmw_zenoh_pico ros-rolling#46 — the rolling + rmw_zenoh_pico pipeline exercising the newer commits, including the rclpy verification above.

Full write-up

All the changes this required, across every repo, are documented together in Tobias-Fischer/ros2-emscripten-zenoh-demo — including a working rclc and rclpy browser demo verified end-to-end against a native zenohd router.

🤖 Generated with Claude Code