Make errno a macro like on other platforms

[RReverser]

Currently wasi-libc makes errno a globally visible thread-local variable: https://github.com/WebAssembly/wasi-libc/blob/38f48942fabf1b59e73bca126340b219fa9a78aa/libc-bottom-half/cloudlibc/src/libc/errno/errno.c#L87

This differs from most other platforms - including underlying musl libc https://github.com/WebAssembly/wasi-libc/blob/38f48942fabf1b59e73bca126340b219fa9a78aa/libc-top-half/musl/include/errno.h#L10-L21 - that define errno as just a macro that calls an internal function.

Would it be possible to change this to align the behaviour? I know it's somewhat niche usecase, but it seems to be the only big difference that prevents linking pre-existing object files produced by clang -target wasm32-wasi with Emscripten executables (https://github.com/emscripten-core/emscripten/issues/19236) as object files depend on errno and it's not declared anywhere except wasi-libc.

[sbc100]

As long as there is no overhead, I don't see why we wouldn't just follow upstream musl on this. However, I think you would need to show that doing so didn't adding any overhead.

[sunfishcode]

ABI compatibility between wasi-libc and Emscripten would be error-prone at best, because the libc's have numerous differences which would lead to silent breakage. Also, while ABI compatibility has its advantages, it also has major ~~advantages~~ disadvantages, and with our current development resources, we can't remotely afford the kinds of costs it would entail to maintain any expectation of ABI compatibility.

[RReverser]

because the libc's have numerous differences which would lead to silent breakage

I know there are some historical differences between filesystem constants, but otherwise they both use musl and seem largely compatible, at least enough to work for my usecase.

I don't want to add undue maintenance burden and certainly don't expect any guarantees on ABI compatibility going forward, but I thought this particular difference is small enough to fix, and, if anything, might make the maintenance tiny bit simpler by reducing customized surface area vs just using what musl does.

[sunfishcode]

I'm not familiar with your use case, but even if it's small today, there's a risk it could grow in scope over time, or that other people might see what you're doing and want to do the same thing. For many projects, those are goals :-).

[RReverser]

That's a risk, yes, and, yes, secretly I'd hope someday Emscripten could actually be compatible with wasi-libc when in STANDALONE_WASM mode, but in this particular project I'm doing so much dangerous stuff already one more thing doesn't change much 😅

But basically I want to link a library built with Rust wasm32-wasi with Emscripten application built in STANDALONE_WASM mode. I could build Rust to wasm32-unknown-emscripten as well but historically that target in Rust is a bit problematic / undermaintained + it's crucial for me for that library to not depend on any of Emscripten's own custom imports which wasm32-unknown-emscripten can't guarantee even in STANDALONE_WASM mode (it all depends on features used) but wasm32-wasi can.

Either way, I thought this particular issue with thread-local might be worth looking at in isolation.