Hacker News Reader

Comment by AgentME | Hacker News Reader

Anything built with emscripten expects the emscripten runtime to be provided for those imports. The default output of emscripten isn't a WASM file that's meant to be used on its own, but a WASM file plus a JS file that sets up the runtime. It looks like they're trying to use the WASM file on its own and running into the problems that come from that.

Standards like WASI are meant to define a common runtime for WASM modules. A WASM module built for WASI would fit the author's expectations better (as they could possibly find an all-in-one WASM+WASI library or attach a WASI implementation to a WASM library to run the WASM file), though I don't know anything about emscripten and WASI compatibility.

Edit: You can use the STANDALONE_WASM emscripten option to make it not depend on the emscripten runtime and use WASI instead. This is what the author should use.

View on HN

It's straightforward to create a WASI executable with Emscripten:

    emcc hello.c -o hello.wasm

This generates a single self-contained .wasm file that's runnable as 'WASI executable':

    wasmtime hello
    Hello World!

Some advice for C/C++ library design to make life easier for users in such 'esoteric environments':

- distribute as source code, ideally as a small number of .h and .c files

- ideally don't distribute any build system files, instead make the library configurable via a handful of preprocessor defines, list those defines in the readme

- don't have builtin IO calls such as fopen/fread/fclose, instead let the library user provide any data to be processed in memory

- don't have built-in multithreading calls, instead provide functions which allow processing data in slices, so that the library user can easily call those 'slice functions' from multiple threads (or a similar solution to prevent multithreading from being baked into the library)

- ideally let the user also override memory allocation functions

Simulate the same experience by getting in you time machine and traveling back to 1972.

True, this advice made sense back in 1972 just as it makes sense today. Means it's probably pretty good advice when it survives for so long ;)

It doesn't sound like that would end up with a particularly pleasant-to-use API. Do you know of any examples??

The STB headers are mostly built like that: https://github.com/nothings/stb

Dear ImGui is a C++ example: https://github.com/ocornut/imgui

You could also add an optional 'convenience layer' over the lower-level flexible-but-inconvenient core library, as long as the core library can be built and used without the convenience layer.

In essence it's just a way to decouple the actually important library functionality from runtime environment details which might be better implemented outside the C and C++ stdlibs anyway.

It's already as simple as the stdlib IO functions not being asynchrononous while many operating systems provide more modern and performant asynchronous IO APIs. For a specific type of library (such as an image decoder) it's often better to delegate such details to the library user instead of either using the stdlib or having the library talk directly to OS APIs.

PS: this type of library design is actually also quite common in game development, because such libraries must be embeddable in game engine code bases which usually implement their own IO-, threading- and memory-management systems.

There's nothing really standard, every environment will have its own APIs. WASI is not going to run in a web browser without additional modules.

If system calls are not required, code can be compiled to `wasm32-freestanding`. That works everywhere, as it ensures that there are no dependencies on external APIs.

When specifically targeting WASI, the code should be compiled to `wasm32-wasi`. That can be done using `clang`, with the addition of a specific libc and the `libclang_rt.builtins-wasm32.a` file.

But the easiest and probably most common way is to use `zig cc`, followed by `-target wasm32-wasi` or `-target wasm32-freestanding`.

For the web, or any environment with Javascript around, Emscripten remains by far the easiest way to go, since it provides a really amazing POSIX emulation.

The problem is that the instructions for actually running the WASM file are not that clear... the docs the author mentions shows how to compile to WASM, which is easy enough, but then here's the instructions to make that actually work in the browser:

https://github.com/libjxl/libjxl/blob/main/tools/wasm_demo/R...

Yeah, you need some mysterious Python script, a JS service worker at runtime, choose whether you want the WASM or WASM_SIMD target, use a browser that supports Threads and SIMD if you chose that, make sure to serve everything with the appropriate custom HTTP headers... just reading that, I can see that to get this stuff working on non-browser WASM targets would likely require expertise in WASM, which is the point of the OP. WASM's UX is just not there yet.

Most of the stuff there has nothing to do with WASM itself though. Loading an running a WASM module is very simple. In this case it’s mostly web craziness like bundling and the hoops you have to jump through to enable some features post-spectre mitigations. Then seemingly that the go runtimes suck.

Reply on news.ycombinator.com