--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/527adec2-ee4d-44f3-a783-ce901632c30cn%40googlegroups.com.
Oki doki, thanks for the clarification. I just wanted to check if I'm missing something, using the wasi-sdk makes sense in that case.Maybe my use case helps a bit to prioritize "proper" WASI support a bit :)I basically want to replace native command line tools (in my case: a shader compiler built out of the the Khronos GLSL compiler, SPIRVTools and SPIRVCross) with a WASI version, because right now I need to build this tool in 4 variants (Windows x86_64, Linux x86_64, macOS x86_64 and macOS arm64) and then "distribute" the binaries through a git repository. My plan is to replace this with a single WASI binary (building on the target machine is also not an option because these are complex C++ dependencies which can take up to 15 minutes to build).
One missing piece in the WASI API is popen() support though. The shader compiler optionally needs to run the proprietaty D3D and Metal shader compilers to generate shader binary blobs. Not sure yet how I'll tackle that eventually, but a WASI executable which just generates shader source code (not binary blobs) would be a good start nonetheless.Cheers!-Floh.--On Tuesday, 14 December 2021 at 17:43:10 UTC+1 s...@google.com wrote:The standalone/wasi support in emscripten is very basic and doesn't have full fileystem support yet. I would certainly recommend using wasi-sdk if you want to run something on wasmtime.If I ever get around to landing this PR then a lot more of the FS stuff might start working: https://github.com/emscripten-core/emscripten/pull/12704. But this has not been a priority recently. The interesting part for me would be that it might allow existing WASI applications to be run in the JS glue code. i.e. take a pre-built wasi module and run `emcc --post-link` to run on the web.On Tue, Dec 14, 2021 at 6:45 AM Floh <flo...@gmail.com> wrote:I'm currently tinkering with Emscripten's WASI output and can't get filesystem access to work. In short, everything compiles, but then when running via:wasmtime --dir . bla.wasm...all filesystem operations fail.When compiling with the clang included in the wasi-sdk it works as expected. Is this something that can be easily fixed or worked around on my side, or should I switch to the wasi-sdk instead?Thanks!--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/527adec2-ee4d-44f3-a783-ce901632c30cn%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/17b87056-ad33-404a-850b-141028b20f43n%40googlegroups.com.
> Unless you plan to run those tools on the web then I think wasi-sdk is most likely the way to go. How do you plan to run the binaries BTW?Currently I'm using wasmtime.I was actually successful to build my shader compiler through wasi-sdk, and run it through wasmtime, the file system access worked as expected.Installing the wasi-sdk is just downloading and unpacking somewhere (e.g. no env-variables or search path updating needed), and then I created a cmake toolchain file which looks a lot like my Emscripten toolchain file, but with all the Emscripten-specific parts removed:
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/484d2d4a-fd79-42a5-b9f7-90cc39b5cce8n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/67a4ca70-36e3-47a5-879c-f4ca6df0d282n%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/a97HaictQLo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ7uW5SZhsrqfi0HFptrsv87QnTzaOixr3L0J26kxJ0GA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CADJ3TLdKqmSEsWZ6_TY4Ef9semHv11ousfda_FbX9Jmiow5XJg%40mail.gmail.com.
Dan Gohman: The original reason is that cloudlibc did it that way, and the code comes from there.
Dan Gohman: From a libc maintainer perspective, these values are implementation details. musl only has a single value because musl only supports Linux, where O_RDONLY always has the same value. But across other platforms, it can have different values.
Dan Gohman: wasi-libc is not ABI-compatible with Emscripten in numerous ways, and no one has ever volunteered to do the work to make it be so.
Dan Gohman: That said, from a practical perspective, some C / POSIX constants are sufficiently "well known" that we do make efforts to align their values with the well-known values. This is somewhat subjective, so whether O_RDONLY should qualify as having a well-known value would come down to how it's used in practice, how you're using it.