-
Notifications
You must be signed in to change notification settings - Fork 92
Closed as not planned
Closed as not planned
Copy link
Description
To reproduce:
$ cat test.c
#include <stdio.h>
int main() {
puts("hello");
}
$ .../wasi-sdk-22.0/bin/clang -target wasm32-wasip1-threads -pthread test.c -o test.wasm
$ jco new test.wasm --wasi-command -o test.component.wasm
(jco componentNew) ComponentError: failed to encode a component from module
$failed to validate component output
Caused by:
type mismatch for export `memory` of module instantiation argument `env`
mismatch in the shared flag for memories (at offset 0x7fd8)
at componentNew (file:///home/whitequark/.npm-packages/lib/node_modules/@bytecodealliance/jco/obj/wasm-tools.js:2462:11)
at componentNew (file:///home/whitequark/.npm-packages/lib/node_modules/@bytecodealliance/jco/src/cmd/wasm-tools.js:58:18)
at async file:///home/whitequark/.npm-packages/lib/node_modules/@bytecodealliance/jco/src/jco.js:134:9
This example is extracted from a larger project (YoWASP Clang). LLVM currently does not compile for the wasm32-wasip1 target (it requires wasm32-wasip1-threads) because it extensively uses atomics even in a single-threaded build. This is difficult to change. However, an LTO build of LLVM/Clang/LLD (with the WebAssembly patchset that's likely going to be accepted in near future) doesn't import thread.spawn and so doesn't need to be treated differently.
Should this restriction be relaxed in jco?
Metadata
Metadata
Assignees
Labels
No labels