Link the Wasm EH runtime under -fwasm-exceptions without requiring C++ (#27496) This makes `-fwasm-exceptions` link the Wasm EH runtime independently of C++ linking. Wasm EH objects can be produced by non-C++ frontends - notably rustc, whose precompiled std uses Wasm exceptions for unwinding and which invokes `emcc` (not `em++`) as its linker. Since `DEFAULT_TO_CXX` was disabled by default in #27469, any rust-driven emcc link now fails with: ``` wasm-ld: error: libstd-*.rlib: undefined symbol: __cpp_exception wasm-ld: error: libpanic_unwind-*.rlib: undefined symbol: _Unwind_RaiseException ``` because both libunwind and the `__cpp_exception` tag (previously defined in libc++abi) were only linked under `LINK_AS_CXX`. The tag and the unwinding runtime are language-agnostic runtime support for the Wasm EH LLVM lowering, not part of the C++ ABI surface. This PR now includes #27498 as its base, which provides the same `_Unwind_*` linkability for the non-Wasm-EH modes on the JS side. What's implemented: * The `__cpp_exception` tag definition moves from libc++abi (`__cpp_exception.S`) into libunwind's `Unwind-wasm.c` as inline asm, matching upstream llvm/llvm-project#185770. * libunwind is linked whenever `WASM_EXCEPTIONS` is enabled, rather than only when linking as C++. Test coverage extends `test_libunwind` from #27498 with `wasm_eh` and `wasm_legacy_eh` variants (completing its TODO), and adds `test_cpp_exception_tag` linking an asm object that throws the tag directly from a C caller - the same reference pattern as rustc-generated catch/throw sites - which fails to link without this change. The now-unneeded `DEFAULT_TO_CXX` workaround is dropped from `test_wasi_with_sjlj`. Existing C++ Wasm EH coverage (`core0.test_exceptions_*`) passes unchanged. _Made with AI assistance under my review_
Main project page: https://emscripten.org
GitHub CI status: 
Chromium builder status: emscripten-releases
Emscripten compiles C and C++ to WebAssembly using LLVM and Binaryen. Emscripten output can run on the Web, in Node.js, and in wasm runtimes.
Emscripten provides Web support for popular portable APIs such as OpenGL and SDL2, allowing complex graphical native applications to be ported, such as the Unity game engine and Google Earth. It can probably port your codebase, too!
While Emscripten mostly focuses on compiling C and C++ using Clang, it can be integrated with other LLVM-using compilers (for example, Rust has Emscripten integration, with the wasm32-unknown-emscripten target).
For detailed instructions and tutorials, visit the Emscripten Website.
There are two primary ways to install Emscripten:
Using the Emscripten SDK (emsdk) (Recommended) The easiest way to get started is by using the Emscripten SDK. Follow the instructions on the downloads page to install it.
From a Git Checkout (Manual Installation) If you have cloned the repository from Git, you can install the dependencies manually and then run the bootstrap script:
./bootstrap.py
For more details, see the developer guide.
Run emcc like you would gcc or clang:
$ emcc hello.c -o hello.js $ node hello.js Hello, world!
Emscripten will compile your code into a WebAssembly module along with a JavaScript file that can load and run it. You can then run the resulting JavaScript in your browser or under Node.js (or Deno or Bun).
Emscripten can also generate a sample HTML page that then loads the JavaScript:
$ emcc hello.c -o hello.html
You can then serve the generated hello.html using the emrun tool, or a web server of your choosing.
For information on how to contribute to the project, see CONTRIBUTING.md and the Contributing section on the website.
Emscripten is available under 2 licenses, the MIT license and the University of Illinois/NCSA Open Source License.
Both are permissive open source licenses, with little if any practical difference between them.
The reason for offering both is that (1) the MIT license is well-known and suitable for a compiler toolchain, while (2) LLVM‘s original license, the University of Illinois/NCSA Open Source License, was also offered to allow Emscripten’s code to be integrated upstream into LLVM. The second reason became less important after Emscripten switched to the LLVM wasm backend, at which point there isn't any code we expect to move back and forth between the projects; also, LLVM relicensed to Apache 2.0 + exceptions meanwhile. In practice you can just consider Emscripten as MIT licensed (which allows you to do pretty much anything you want with a compiler, including commercial and non-commercial use).
See LICENSE for the full content of the licenses.