The WebAssembly target seems to have been designed to be always passed a
--sysroot, likely because of being tested to work only with the
WASI-SDK. This results into passing bare, non-existing paths in include
paths, such as:
-internal-isystem /include/wasm32-wasi -internal-isystem /include
(and similar for /lib/).
In Debian, the wasi-libc package ships its files in
/usr/include/wasm32-wasi, /usr/lib/wasm32-wasi etc.
Add support in the target for including paths from /usr as well. To
avoid changing the code in more intrusive ways (to do e.g. what the
Linux target does) add a bit of an indirection where the "sysroot"
defaults to "/usr" instead of the empty string. This should probably be
adjusted a bit if it were to be upstreamed.
Closes: #1020746
Our packaging overrides the upstream choice for rtlib to default always
to libgcc. Unfortunately, libgcc is not available for WebAssembly
(wasm32/wasm64 targets). This makes every build to -target
wasm32-unknown-wasi fail, unless one passes --rtlib=compiler-rt.
Patch the upstream source to default, and only accept, compiler-rt for
the WebAssembly target to make everything work out of the box. This
mirrors similar code that the upstream Darwin and Fuchsia targets have.
GCC seems fairly far from supporting WebAssembly. If/when that day
comes, this patch can be dropped.
Current shortcomings/future work:
* Unfortunately this currently takes the form of a separate, standalone
build (with the just-built stage2 toolchain), which makes this a
little more convoluted. The upstream compiler-rt build system does
not have a way (that I could find) to manually add additional targets
to the build.
* GNU strip (binutils) does not understand the WebAssembly binary, so
dh_strip fails. llvm-strip does, but a) does not understand all the
arguments that dh_strip passes (e.g. -N), b) fails with "invalid
relocation offset" on --strip-debug (but works with --strip-all).
This currently passes -X to dh_strip to exclude them from being
stripped entirely. Invoking llvm-strip manually with --strip-all can
be considered in the future.
* The wasm32/wasm64 binaries are, by design, architecture-independent.
With this commit, they are being built in every architecture, and
shipped in the libclang-common-X.Y-dev package, which is arch: any,
but ships both architecture-dependent (native/host compiler-rt) and
architecture-independent files (include headers etc.).
In a future iteration, the wasm32/wasm64 compiler-rt library could be
factored out to a separate (arch: all) package. This is left
outstanding because it should probably happen alongside a different
split for libclang-common-X.Y-dev that will include splitting the
native libclang-rt as well.
Closes: #1010932
The WebAssembly target seems to have been designed to be always passed a
--sysroot, likely because of being tested to work only with the
WASI-SDK. This results into passing bare, non-existing paths in include
paths, such as:
-internal-isystem /include/wasm32-wasi -internal-isystem /include
(and similar for /lib/).
In Debian, the wasi-libc package ships its files in
/usr/include/wasm32-wasi, /usr/lib/wasm32-wasi etc.
Add support in the target for including paths from /usr as well. To
avoid changing the code in more intrusive ways (to do e.g. what the
Linux target does) add a bit of an indirection where the "sysroot"
defaults to "/usr" instead of the empty string. This should probably be
adjusted a bit if it were to be upstreamed.
Closes: #1020746
Our packaging overrides the upstream choice for rtlib to default always
to libgcc. Unfortunately, libgcc is not available for WebAssembly
(wasm32/wasm64 targets). This makes every build to -target
wasm32-unknown-wasi fail, unless one passes --rtlib=compiler-rt.
Patch the upstream source to default, and only accept, compiler-rt for
the WebAssembly target to make everything work out of the box. This
mirrors similar code that the upstream Darwin and Fuchsia targets have.
GCC seems fairly far from supporting WebAssembly. If/when that day
comes, this patch can be dropped.
Current shortcomings/future work:
* Unfortunately this currently takes the form of a separate, standalone
build (with the just-built stage2 toolchain), which makes this a
little more convoluted. The upstream compiler-rt build system does
not have a way (that I could find) to manually add additional targets
to the build.
* GNU strip (binutils) does not understand the WebAssembly binary, so
dh_strip fails. llvm-strip does, but a) does not understand all the
arguments that dh_strip passes (e.g. -N), b) fails with "invalid
relocation offset" on --strip-debug (but works with --strip-all).
This currently passes -X to dh_strip to exclude them from being
stripped entirely. Invoking llvm-strip manually with --strip-all can
be considered in the future.
* The wasm32/wasm64 binaries are, by design, architecture-independent.
With this commit, they are being built in every architecture, and
shipped in the libclang-common-X.Y-dev package, which is arch: any,
but ships both architecture-dependent (native/host compiler-rt) and
architecture-independent files (include headers etc.).
In a future iteration, the wasm32/wasm64 compiler-rt library could be
factored out to a separate (arch: all) package. This is left
outstanding because it should probably happen alongside a different
split for libclang-common-X.Y-dev that will include splitting the
native libclang-rt as well.
Closes: #1010932
