cc,wasi: ship WASI libc and autobuild it when needed

[kubkon]

Closes #8489

Tl;dr

Zig now ships with wasi-libc and hence we can now easily cross-compile C to WASI with Zig! No more need to do this yourself by compiling wasi-libc and/or wasi-sdk. Just download Zig, and you're sorted:

> zig cc hello.c -target wasm32-wasi
> wasmtime a.out
Hello, World!

More detailed description of changes to Zig

cc @andrewrk @fengb @jedisct1 @Luukdegram @ifreund as I'd love to learn your opinion about these changes!

1. First of, wasi-libc is a weird being since it bundles up modified versions of a few libraries including cloudlibc, musl, dmalloc, etc. Because of the fact the libs are non-stock, I've not tried to find similarities with standard musl we already bundle with Zig. However, I have significantly slimmed down the wasi-libc sources we bundle with Zig compared to the ones hosted by the WebAssembly CG. Some numbers:

Taken disk space:

• lib/libc/wasi sources: 12M
• lib/libc/include/wasm-wasi-musl headers: 992K

2. I've added a few changes to how we name Wasm artifacts to match the convention used in wasi-libc, and so, static archives are now named exactly as on any POSIX-compliant OS libName.a, object files are left as they were so name.o.wasm, and finally, dynamic libraries are named libName.wasm but I'm happy to revert this last change to what it was name.wasm. while the rest is left intact, so objects name.o.wasm, Wasm library modules name.wasm, and executables name.wasm.

3. I had to add some additional logic to link/Wasm.zig to actually link in the compiled crts and wasi-libc but I based it largely on the logic used in link/Elf.zig. One thing that is still missing is ability to create reactors and commands: we actually compile the necessary crts but I've not yet worked out what commands the user should specify to generate a reactor say instead of a standard binary.

EDIT - 20/05/2021:

4. I've signifcantly simplified the building logic in Compilation.zig by virtue of the fact that we now allow for creation of static Wasm archives. However, to make the changes backwards compatible, plus it simply makes more sense, I've ensured that when the user builds a Wasm library, they create an actually Wasm module hence the build process involves invoking wasm-ld rather than ar. This can of course be overwritten by specifying an appropriate flag when building the lib such as:

> zig build-lib add.zig # -> produces simple.wasm lib module
> zig build-lib add.zig -static # -> produces libsimple.a archive which can further be fed to wasm-ld
> zig build-lib add.zig -dynamic # -> equivalent to no option, produces simple.wasm lib module

[jedisct1]

Looks like some headers are missing:

zig cc a.c -target wasm32-wasi

/opt/zig/lib/zig/libc/wasi/libc-bottom-half/crt/crt1-command.c:1:10: fatal error: cannot open file '/opt/zig/lib/zig/libc/wasi/libc-bottom-half/headers/private/wasi/api.h': No such file or directory
#include <wasi/api.h>

[kubkon]

Looks like some headers are missing:

zig cc a.c -target wasm32-wasi

/opt/zig/lib/zig/libc/wasi/libc-bottom-half/crt/crt1-command.c:1:10: fatal error: cannot open file '/opt/zig/lib/zig/libc/wasi/libc-bottom-half/headers/private/wasi/api.h': No such file or directory
#include <wasi/api.h>

Weird. What's a.c btw?

[kubkon]

@jedisct1 I can't repro your issue on some dummy examples including the official Wasmtime's capability example. I was wondering though, might it be that clearing Zig's global cache ~/.cache/zig might help?

[srenatus]

❤️ wasm related improvements. thank you!