Allow WASI-less builds with --triple wasm32-unknown-unknown
#2412
Labels
enhancement
New feature or request
Comments
Yes, ICU depends on wasi-libc and WASI API. And anothet big blocker is that C++ part of stdlib heavily depends on libcxx and libc. So if we want to make a non-wasi binary, we need a wasi-less libc. If wasi-libc provide a subset of the libc APIs that are able to implement without WASI APIs, it would be a great first step. |
|
I guess the libcxx dependency is caused by Swift runtime? I wonder how easily that depedency could be removed, or should we just stick to libcxx and hope that DCE will make it slim enough? |
|
I think it's not easy to remove libcxx dependency completely. But libcxx has many options and it works on bare-metal environment, so I think libcxx can be built upon wasi-less libc. |
Here is linker errors when not passing -lcAnd here is imports list after DCEed by This shows we only uses WASI API in |
|
Our maybe if we prefer a libc written C it would make more sense to fork WASI-libc and strip it of WASI dependencies and stuff we don't need in WASI-less builds, like time/threads/FS etc? |
|
@MaxDesiatov Thanks for researching 😄 I took a look at metallic, but it's designed to be used with a JavaScript environment, so it doesn't match our requirements... I wondered some ways to provide wasi-less libc:
|
|
With the option 3 would we just avoid using WASI-related APIs and rely on DCE to exclude them? Or would a build script exclude them somehow? I think a combination of 2 and 3 looks most reliable long term. |
|
Fortunately, musl and cloudlibc implements each libc API in separated files, so the build script can exclude WASI-related APIs easily and don't have to rely on DCE, I think. So with option 3, only what we need to do is to write a Makefile. |
|
BTW, Saleem previously mentioned he'd like to see WASI-libc to be compatible with CMake for it be properly used in upstream Swift, so maybe what we really need to write is a |
|
Could the removal of the ICU dependency allow for WASI-less builds? |
|
I think, potentially yes. There's already some |
|
Is there some way I could use this triple with |
|
Unfortunately, not until this is supported in the toolchain itself |
|
OK, thanks. Looking forward to WASI-less builds! |
|
Hi! Any news about WASI-less builds? Many blockchains infrastructures require no WASI builds and Swift can be an AWESOME language for wasm smart contract coding! |
|
@gfusee If you want a WASI-less build now, you can just replace WASI imports with unreachable instruction by wasm-snip |
|
The upcoming Swift 6.0 will support See Max's forum post for more details: https://forums.swift.org/t/some-feedback-from-my-short-experience-with-swiftwasm/69605/5 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Most probably depends on #2411, as ICU requires libc I guess? 🤔
Making this available as a separate triple allows us to ship both WASI-linked and WASI-less stdlib simultanously. Then people who need WASI (i.e. everyone who needs Foundation for example) can build with existing
--triple wasm32-unknown-wasi, while--triple wasm32-unknown-unknownis available as an option for slim builds that don't need Foundation.The text was updated successfully, but these errors were encountered: