* More WebAssembly (wasm32/wasm64) work:
- Update patch wasm-sysroot-usr to stop including /usr/include when
building for the non-OS (unknown) wasm targets, to avoid inadvertently
including the host's (glibc) headers.
- Re-enable builds on all architectures, previously disabled for
arm64 armel mips64el mipsel ppc64el armhf in 1:14.0.6-4, due to an FTBFS
related to the /usr/include issue above.
- Update patch wasm-sysroot-usr to adjust system include paths for C++
headers as well.
- Build libc++ and libc++abi for wasm32-wasi, generating two new binary
packages, and introducing a build dependency on wasi-libc.
- Misc code organization fixes to debian/rules.
Do a standalone build of libcxx/libcxxabi, for wasm32-wasi. libcxx
requires a libc, and thus this requires a new build dependency on
wasi-libc. wasi-libc is not currently available for wasm64, so limit the
build to wasm32.
This introduces two new binary packages:
- libc++-${LLVM_VERSION}-dev-wasm32
- libc++abi-${LLVM_VERSION}-dev-wasm32
There isn't currently a naming convention in Debian for WebAssembly. Use
a "-dev-wasm32" suffix, which makes it consistent with packages such as
"libc6-dev-i386" and "libstd-rust-dev-wasm32".
Given these builds are specific to WASI, it can be argued that the names
should be something like "-dev-wasm32-wasi", or simplified to
"-dev-wasi" (not very future proof) or "-dev-wasi32" (not something
upstream uses). Something to think through later on.
WebAssembly only supports shared linking, hence why we -dev packages are
provided, shipping development headers and static archives.
In wasm-sysroot-usr.diff we have changes to support compilation without
a sysroot and with system paths. These so far have applied to the C
include paths (among other things), i.e. /usr/include/<triple>. This was
mainly because that's what I had at hand to test and wanted to keep
things limited as a first iteration.
Now that we're iterated on it and cleared out some issues, make the
exact same changes for the C++ include paths as well, i.e.
/usr/include/<triple>/c++/v1. Nothing installs anything on those paths
there yet, so this is mostly preparatory for subsequent changes.
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.
because we want the clang stage 1 to be as reproducible as possible
when building with sccache (because this tool do a hash using the
compiler binary and other things)
