Crafter.Build/packaging/flatpak/wasi-sdk-asm-target.patch
Jorijn van der Graaf a902b32938
fix(packaging): assemble compiler-rt's wasm stubs for wasm32
wasi-sdk's sysroot build hands its compiler-rt sub-build
CMAKE_C_COMPILER_TARGET but nothing for the ASM language, so the two
wasm/*.S stubs in the builtins (the setjmp/longjmp and C++ exception
tags) were assembled for x86-64. wasm-ld warned on every wasm link that
the archive members were neither Wasm objects nor bitcode, and anything
that reaches those tags, which crafter-build's -wasm-enable-sjlj does,
would fail to link. wasi-sdk's own toolchain never sees it because its
clang defaults to wasm32-wasip1; the sysroot-only mode against a host
clang does. A one-line patch adds CMAKE_ASM_COMPILER_TARGET to that
sub-build; it belongs upstream.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-02 23:29:42 +02:00

20 lines
977 B
Diff

wasi-sdk-sysroot.cmake: tell the compiler-rt sub-build the ASM target too
The sub-build gets CMAKE_C_COMPILER_TARGET but nothing for the ASM
language, so compiler-rt's wasm/*.S stubs (the setjmp/longjmp and C++
exception tags) are assembled for the host when the driving clang is not
a wasm-default build. wasm-ld then warns that the archive members are
neither Wasm objects nor bitcode, and code that needs the tags fails to
link. wasi-sdk's own toolchain hides this because its clang defaults to
wasm32-wasip1; the sysroot-only mode against a host clang does not.
--- a/cmake/wasi-sdk-sysroot.cmake
+++ b/cmake/wasi-sdk-sysroot.cmake
@@ -107,6 +107,7 @@
-DCOMPILER_RT_BUILD_ORC=OFF
-DCOMPILER_RT_BUILD_GWP_ASAN=OFF
-DCMAKE_C_COMPILER_TARGET=${target}
+ -DCMAKE_ASM_COMPILER_TARGET=${target}
-DCMAKE_C_FLAGS=${WASI_SDK_CPU_CFLAGS}
-DCMAKE_CXX_FLAGS=${WASI_SDK_CPU_CFLAGS}
-DCMAKE_ASM_FLAGS=${WASI_SDK_CPU_CFLAGS}