Personally, although I do use wasi-sdk (clang) and the wasm32-unknown-wasi triple, the result can be basically free-standing, depending on what flags you use.
As a sibling post said, optimization matters, and using wasm-ctor-eval and wasm-opt also helps. But it's useful to keep full C semantics.
> Personally, although I do use wasi-sdk (clang) and the wasm32-unknown-wasi triple, the result can be basically free-standing, depending on what flags you use.
This is what I've been doing for my little non-WASI runtime. For my minimal programs I find only a few wasi exports are required, which don't appear to actually be used and I just stub them out. Would love to figure out how to get rid of the code depending on them entirely but it's lower priority.
If it's possible that it's stuff that's being used at initialization time, wasm-ctor-eval might help.
Also, you probably want to build a reactor (-mexec-model=reactor) if that's not what you're already doing. A command will use WASI to read command-line arguments and environment.
But it's hard to tell without knowing the specific imports you're trying to get rid of.
Thanks. This is awesome. For the emulator I wrote my own 200 line libc implementation with a five line malloc routine [0]. Nice to see another implementation, which does a little bit more.
Personally, although I do use wasi-sdk (clang) and the wasm32-unknown-wasi triple, the result can be basically free-standing, depending on what flags you use.
As a sibling post said, optimization matters, and using wasm-ctor-eval and wasm-opt also helps. But it's useful to keep full C semantics.