libclang-rt-X.Y-dev (including polly)
* the wasm targets are shipped into libclang-rt-14-dev-wasm32
and libclang-rt-14-dev-wasm64
* libclang-common-X.Y-dev arch moved to all
* 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.
