You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently trying to build a command-line tool into WASM using emscripten.
The repository that builds this tool has a fairly complex build process (involving automake, libtool and hundreds of build steps), but thankfully it depends only on quite standard libraries, so thanks to Emscripten's support for zlib I managed to actually compile to WASM, and get a first version of the program running with emscripten's JS and HTML page. :-)
However, I was hoping to make it run as a standard WASI component to make it more portable.
Therefore I've tried the STANDALONE_WASM option as per the documentation (as well as a "PURE_WASI" option that I saw mentioned in tickets here, but seems to have no effect). And while the standalone WASM has fewer dependencies to the emscripten "env", it's still not, well, standalone.
Viewing the generated imports in wasm2wat, I see the following imports :
And as you can see, 4 filesystem calls remain untranslated to WASI : faccessat, rmdir, unlinkat, getdents64.
I know that some functionality of emscripten is not easily implemented in WASI (I've read thinks around exception management, etc.), but those seem to be fairly simple file system operations.
In particular, among those the WASI spec clearly specifies that the "path_remove_directory" is equivalent to POSIX unlinkat (cf. https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/docs.md#-path_remove_directoryfd-fd-path-string---result-errno ).
Is there any reason why these calls are not mapped to WASI in standalone mode ?
Here are my build details :
Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.72 (437140d)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 1c4caece05f1885ba6ed80755d6b5de1b9f99579)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /emscripten/emsdk/upstream/bin
Hi,
I'm currently trying to build a command-line tool into WASM using emscripten.
The repository that builds this tool has a fairly complex build process (involving automake, libtool and hundreds of build steps), but thankfully it depends only on quite standard libraries, so thanks to Emscripten's support for zlib I managed to actually compile to WASM, and get a first version of the program running with emscripten's JS and HTML page. :-)
However, I was hoping to make it run as a standard WASI component to make it more portable.
Therefore I've tried the STANDALONE_WASM option as per the documentation (as well as a "PURE_WASI" option that I saw mentioned in tickets here, but seems to have no effect). And while the standalone WASM has fewer dependencies to the emscripten "env", it's still not, well, standalone.
Viewing the generated imports in wasm2wat, I see the following imports :
And as you can see, 4 filesystem calls remain untranslated to WASI : faccessat, rmdir, unlinkat, getdents64.
I know that some functionality of emscripten is not easily implemented in WASI (I've read thinks around exception management, etc.), but those seem to be fairly simple file system operations.
In particular, among those the WASI spec clearly specifies that the "path_remove_directory" is equivalent to POSIX unlinkat (cf. https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/docs.md#-path_remove_directoryfd-fd-path-string---result-errno ).
Is there any reason why these calls are not mapped to WASI in standalone mode ?
Here are my build details :
Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.72 (437140d)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 1c4caece05f1885ba6ed80755d6b5de1b9f99579)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /emscripten/emsdk/upstream/bin
Linking command
Thanks !
The text was updated successfully, but these errors were encountered: