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.

Reply via email to