Enable real pthreads for emscripten-wasm32 builds

[Tobias-Fischer]

Summary

Flips USE_PTHREADS 0→1 (compile and link) for every emscripten-wasm32ament_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

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-wasm32ament_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.
• Drops a build:-side requirement on a build-platform copy of rosidl_default_generators for emscripten cross builds — unsatisfiable (no such native package generally exists) and unnecessary (the host-prefix copy already suffices for CMake's find_package()).
• 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.

Testing

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 rclcandrclpy browser demo verified end-to-end against a native zenohd router.

🤖 Generated with Claude Code