You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My understanding is that setting GOOS=wasip1 GOARCH=wasm should produce identical output as passing the -target wasi command line flag, but it doesn't. Rather, it seem to match -target wasm.
Repro:
package main
funcmain() {
println("Hello, World!")
}
They should be identical, but test3 is importing from gojs, and is also exporting go_scheduler. It's identical to test2, whereas I would expect it to match test1.
The text was updated successfully, but these errors were encountered:
Maybe we should just remove this special case? It means that people that currently rely on the extension will have to provide some explicit flags or environment variables, but it's certainly more explicit and less "magic".
(I think it was originally introduced when wasm was mostly a browser thing and WASI didn't really exist yet).
Currently this overrides GOOS/GOARCH, which are also used for wasm.
This will break people who rely on a command like this:
tinygo build -o foo.wasm path/to/package
They will need to update to explicitly set the target, for example:
tinygo build -o foo.wasm -target=wasm path/to/package
Fixes: #4439
My understanding is that setting
GOOS=wasip1 GOARCH=wasm
should produce identical output as passing the-target wasi
command line flag, but it doesn't. Rather, it seem to match-target wasm
.Repro:
You'll need
wasm2wat
from The WebAssembly Binary Toolkit.Then:
Open each wat file in a text editor. Imports are near the top, exports are near the bottom.
test1.wat
test2.wat / test3.wat
They should be identical, but test3 is importing from
gojs
, and is also exportinggo_scheduler
. It's identical to test2, whereas I would expect it to match test1.The text was updated successfully, but these errors were encountered: