Header constants like O_CREAT should not be a problem between wasm and the host. WASI defines a very clear API between wasm and the runtime, and those constants are not part of it. That is, "wasi-sdk host" is a confusing way to put it: there are VMs with WASI support, but they are not tied to the wasi-sdk toolchain, which is just one toolchain that emits WASI.
(Of course, header constants *can* be an issue if you link wasm object files together that were built using different SDKs or even different versions of the same SDK.) Emscripten could add more complete WASI support, if that were useful - it's just a matter of implementing the APIs. PRs would be welcome! On Sat, Feb 5, 2022 at 9:59 AM [email protected] <[email protected]> wrote: > My own observations mixing Emscripten and WASI-SDK are that some > constants, e.g. `O_CREAT` are different in Emscripten (0x64) to Wasi-SDK > (0x10000000). Allowing emscripten to build something that would run under > a wasi-sdk host, like wasmtime, is tricky - I think. > > On Friday, December 17, 2021 at 8:01:14 AM UTC-5 Floh wrote: > >> Ah alright, that toolchain file looks a lot simpler (it's under >> "share/cmake" in the SDK download). I'll use that as base for my own cmake >> toolchain file instead. Thanks! >> >> On Thursday, 16 December 2021 at 21:18:46 UTC+1 [email protected] wrote: >> >>> On Thu, Dec 16, 2021 at 5:53 AM Floh <[email protected]> wrote: >>> >>>> > 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: >>>> >>>> >>>> https://github.com/floooh/fips/blob/master/cmake-toolchains/wasisdk.toolchain.cmake >>>> >>> >>> FYI wasi-sdk includes a cmake toolchain fail upstream: >>> https://github.com/WebAssembly/wasi-sdk/blob/main/wasi-sdk.cmake >>> >>> Maybe we forgot to include it in the download? But it should be usable >>> I think. >>> >>> >>>> The only problem (vs the Emscripten SDK) was that the wasi-sdk doesn't >>>> come with pthread headers/stubs, so I had to tinker a bit with the >>>> glslangValidator source code (which for some reason needs thread-local data >>>> and mutexes, but then doesn't actually spawn any threads). >>>> >>>> The popen() calls (to run native Metal or D3D shader compiler >>>> executables) simply seem to fail at runtime (which I'm already handling in >>>> my code). >>>> >>>> All in all pretty smooth sailing, at the moment it's just an experiment >>>> though, but a promising one :) >>>> >>>> >>>> On Tuesday, 14 December 2021 at 23:41:10 UTC+1 [email protected] wrote: >>>> >>>>> On Tue, Dec 14, 2021 at 9:28 AM Floh <[email protected]> wrote: >>>>> >>>>>> 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). >>>>>> >>>>> >>>>> 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? >>>>> >>>>> >>>>>> >>>>>> 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 [email protected] 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 <[email protected]> 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 [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/emscripten-discuss/527adec2-ee4d-44f3-a783-ce901632c30cn%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/527adec2-ee4d-44f3-a783-ce901632c30cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> 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 [email protected]. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/emscripten-discuss/17b87056-ad33-404a-850b-141028b20f43n%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/17b87056-ad33-404a-850b-141028b20f43n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/emscripten-discuss/484d2d4a-fd79-42a5-b9f7-90cc39b5cce8n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/emscripten-discuss/484d2d4a-fd79-42a5-b9f7-90cc39b5cce8n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/67a4ca70-36e3-47a5-879c-f4ca6df0d282n%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/67a4ca70-36e3-47a5-879c-f4ca6df0d282n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ7uW5SZhsrqfi0HFptrsv87QnTzaOixr3L0J26kxJ0GA%40mail.gmail.com.
