* 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.
