Allow building when targeting WASI

[anuraaga]

WASI is similar to emscripten, providing a syscall layer to WebAssembly focused on server side applications. There are some config knobs that are in place to allow building the repo for emscripten which also need to support wasi (as built with LLVM). Aside from that, there are still some features it supports less than escripten, for example related to signals, causing the build to be even more limited for it.

[anuraaga]

WebAssembly is an architecture, such as x86, not an operating system, which is a syscall layer so in its case, either Emscripten or WASI currently. I have changed this to clarify, as Emscripten is a WebAssembly "OS" which supports mmap while WASI does not.

I can add wasi to this list if it makes sense, but I suspect that would be a bigger decision on whether the project officially supports the OS now or not. But it would be great if we can at least add smaller fixes like this PR on a best-effort basis to allow compilation to pass to encourage the use of abseil within the server-side WebAssembly community

[anuraaga]

It seems that Emscripten does support this codepath while wasi doesn't so I added a wasi-specific option here

[anuraaga]

To build, I did

docker run -it --rm -v `pwd`:/workspace --workdir /workspace ghcr.io/webassembly/wasi-sdk:wasi-sdk-20 bash
# Install nano and modify /usr/share/cmake/wasi-sdk.cmake to add threads to triplet and cflags, following https://github.com/WebAssembly/wasi-sdk/blob/main/wasi-sdk-pthread.cmake because the docker image does not currently include it
mkdir build
cmake -DCMAKE_CXX_FLAGS="-D_WASI_EMULATED_SIGNAL" -DCMAKE_CXX_STANDARD=14 ..
cmake --build . --target all

-D_WASI_EMULATED_SIGNAL is needed because even with the changes to some of the signal-related configs in this PR, the header itself is included either way and this allows the include to work with a stubbed file

[anuraaga]

/cc @sbc100 @abrown in case any questions about wasi-sdk come up I'm not familiar with

Also, just in case it helps to have a use case in mind, I compile RE2 to WASI for loading in Go apps.

https://github.com/wasilibs/go-re2

But RE2 has migrated to using absl and so newer versions of RE2 can't be compiled for that use anymore. It would be great if that can continue to work if it's possible. /cc @junyer FYI

[anuraaga]

In ec9fa08 I went ahead and added a wasi guard for the signal header file in thread_identity to at least allow that file to compile without the stubbed header file enabled via -D_WASI_EMULATED_SIGNAL. In other files, it is not as simple as just guarding, but I think this file, through its usage in logging, has a large impact on downstream so could be worth it, but I can revert if it's adding too many branches

[derekmauro]

I'm testing this now. WASI won't receive official support, but this PR is simple enough that if it works, we can take it.