If you want to build something like libpng (or a myriad of other C libraries,) you need setjmp/longjmp. Not really a huge problem: Emscripten can handle this, it just needs a tiny bit of help via host functions. You can also use Wasm Exception Handling instead, in which case you don't need any hacks on the host side.

So far this sounds pretty good, but actually it isn't, because:

- Wasm Exception Handling is still not part of the standard. They are supported by browsers and runtimes based on browsers, but they are unsupported by lots of other runtimes (Wazero doesn't seem to support them, for example.)

- When you're using Emscripten outside of a browser, you can use the Emscripten method for sjlj support even in a "standalone" build, calling into some simple host functions, which is handy. The problem is... standalone builds with Emscripten don't really work that well. A lot of the syscalls don't really go anywhere: https://github.com/emscripten-core/emscripten/blob/main/syst...

A non-standalone build is possible, but even though Emscripten does use WASI for many things automatically, a lot of host support is required to make this work properly, so outside of a browser environment I reckon this will take a lot of work, and it seems also that it will be hard to properly implement those functions in many of the standalone Wasm runtimes.

You can compile with a Clang/WASI toolchain instead, which will implement much more of the syscalls via WASI, but I don't think this supports the Esmcripten method for handling Wasm Exception Handling, which means you need to have a runtime with Wasm Exception Handling support.

I guess the Clang/WASI toolchain is doing the right thing here, but it's still somewhat frustrating that Wasm Exception Handling is still not a part of the standard or many of the non-browser runtimes.