As previously discussed, both Andrew and I are not particularly happy with wasi-libc. It can get the job done, but it's not exactly a shining example of good engineering practices, consisting of ~5 different upstream codebases plus wasi-libc's own code. It's a pain to deduplicate its code vs the upstream musl we ship, and we have problems with header search paths almost every time we have to touch the bundled wasi-libc code because of its highly confusing directory structure, which is a direct result of being an amalgamation of multiple codebases.
I have no particular issue with the people who work on wasi-libc and are trying to make the best of a codebase with a messy history, but I don't believe this is a good foundation to build upon. If this PR is merged, we will pursue #35379 as Zig's way of providing libc on WASI.
Please note that this PR is slated for Zig 0.18.0; 0.17.0 will still ship with wasi-libc.
Open question: I've removed all traces of wasi-libc in this PR. An alternative approach would be to leave in the support in std so that people can bring their own wasi-libc sysroot using --libc/ZIG_LIBC. Is that a use case we expect to be significant enough to maintain this code?
closes https://github.com/ziglang/zig/issues/9342
closes https://github.com/ziglang/zig/issues/15005
closes https://github.com/ziglang/zig/issues/20747
closes https://github.com/ziglang/zig/issues/22570
closes #30977
As previously discussed, both Andrew and I are not particularly happy with wasi-libc. It can get the job done, but it's not exactly a shining example of good engineering practices, consisting of ~5 different upstream codebases plus wasi-libc's own code. It's a pain to deduplicate its code vs the upstream musl we ship, and we have problems with header search paths almost every time we have to touch the bundled wasi-libc code because of its highly confusing directory structure, which is a direct result of being an amalgamation of multiple codebases. I have no particular issue with the people who work on wasi-libc and are trying to make the best of a codebase with a messy history, but I don't believe this is a good foundation to build upon. If this PR is merged, we will pursue https://codeberg.org/ziglang/zig/issues/35379 as Zig's way of providing libc on WASI. Please note that this PR is slated for Zig 0.18.0; 0.17.0 will still ship with wasi-libc. Open question: I've removed all traces of wasi-libc in this PR. An alternative approach would be to leave in the support in std so that people can bring their own wasi-libc sysroot using `--libc`/`ZIG_LIBC`. Is that a use case we expect to be significant enough to maintain this code? closes https://github.com/ziglang/zig/issues/9342 closes https://github.com/ziglang/zig/issues/15005 closes https://github.com/ziglang/zig/issues/20747 closes https://github.com/ziglang/zig/issues/22570 closes https://codeberg.org/ziglang/zig/issues/30977