compiler-rt WebAssembly builds were failing, and as a workaround commit
ca9dbba introduced COMPILER_RT_WASM_ENABLE, disabling its compilation on
several architectures (arm64 armel mips64el mipsel ppc64el armhf).
This was ultimately caused by the WebAssembly driver including paths in
bare /usr/include, when compiling for wasnNN-unknown-unknown targets.
This in turn resulted in this chain of include paths when building
compiler-rt, as one example out of many:
1. compiler-rt/lib/builtins/divtf3.c:15 #include "fp_lib.h"
2. compiler-rt/lib/builtins/fp_lib.h:23 #include "int_lib.h"
3. compiler-rt/lib/builtins/int_lib.h:93 #include <limits.h>
4. /usr/lib/llvm-14/lib/clang/14.0.6/include/limits.h:20 #if __has_include_next(<limits.h>) #include_next <limits.h>
5. /usr/include/limits.h:26 #include <bits/libc-header-start.h>
6. fatal error: 'bits/libc-header-start.h' file not found
/usr/include/stdint.h is the host's glibc header, and
bits/libc-header-start.h doesn't exist for the wasm targets. This is the
case with or without wasi-libc, as wasi-libc is musl-based and doesn't
have these paths at all.
The only reason builds worked on amd64 is accident:lly the B-D chain
brings in libc6-dev-i386 (through g++-multilib), which creates this
symlink:
/usr/include/bits -> x86_64-linux-gnu/bits
This effectively meant that on amd64 builds, compiler-rt for wasm
targets was compiled with glibc x86_64 headers.
Ultimately this was rooted on the sysroot-based assumptions that the
upstream driver makes and that we are patching (evidently incompletely)
with our wasm-sysroot-usr.diff patch.
Update our patch to explicitly NOT include the bare /usr/include path on
non-OS targets (wasm32-unknown-unknown etc.), while keeping existing
behavior for backwards compatibility when --sysroot is passed.
Given this should (fingers crossed) address this invariance between
amd64 and other architectures, and unbreak those builds, revert commit
ca9dbba and the COMPILER_RT_WASM_ENABLE flag.
b91115bd58