Update the wasm-sysroot-usr.diff patch to restore functionality that was
accidentally dropped when the patch was forward-ported from 14 to 15.
This resolves an issue in which clang++ builds would fail if
libc++-15-dev was installed alongside libc++-15-dev-wasm32.
This issue was rightfully caught in the autopkgtests, and has prevented
the package from migrating to testing, something that should hopefully
be resolved now.
Closes: #1029010, #1032317
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.
