Description
Hi! I'm using tinygo 0.34.0 and experiencing strange behavior when trying to compile to wasi (preview 1).
I'm surprise those 3 commands do not produce the same binary:
$ GOARCH=wasm GOOS=wasip1 tinygo build hello.go
$ GOARCH=wasm GOOS=wasip1 tinygo build -o hello.wasm hello.go
$ tinygo build -target wasip1 -o hello.wasm
First, what is the preferred way to specify the target between -target
and GOOS=wasip1
? And what is the difference? The binary sizes don't match, but they seem to do the same thing.
Second, specifying the output seems to override the GOOS
(second command). In my case, the first and third commands produce binaries whose imports only com from wasp1:
(import "wasi_snapshot_preview1" "fd_write" (func $runtime.fd_write (type 5)))
(import "wasi_snapshot_preview1" "clock_time_get" (func $runtime.clock_time_get (type 18)))
(import "wasi_snapshot_preview1" "args_sizes_get" (func $runtime.args_sizes_get (type 6)))
(import "wasi_snapshot_preview1" "args_get" (func $runtime.args_get (type 6)))
(import "wasi_snapshot_preview1" "random_get" (func $__imported_wasi_snapshot_preview1_random_get (type 6)))
but the second also imports from gojs
:
(import "gojs" "runtime.ticks" (func $runtime.ticks (type 20)))
(import "wasi_snapshot_preview1" "fd_write" (func $runtime.fd_write (type 4)))
(import "gojs" "syscall/js.valueGet" (func $syscall/js.valueGet (type 21)))
(import "gojs" "syscall/js.valuePrepareString" (func $syscall/js.valuePrepareString (type 12)))
(import "gojs" "syscall/js.valueLoadString" (func $syscall/js.valueLoadString (type 22)))
(import "gojs" "syscall/js.finalizeRef" (func $syscall/js.finalizeRef (type 15)))
(import "gojs" "syscall/js.stringVal" (func $syscall/js.stringVal (type 23)))
(import "gojs" "syscall/js.valueSet" (func $syscall/js.valueSet (type 24)))
(import "gojs" "syscall/js.valueLength" (func $syscall/js.valueLength (type 16)))
(import "gojs" "syscall/js.valueIndex" (func $syscall/js.valueIndex (type 25)))
(import "gojs" "syscall/js.valueCall" (func $syscall/js.valueCall (type 17)))
(import "wasi_snapshot_preview1" "random_get" (func $__imported_wasi_snapshot_preview1_random_get (type 5)))
It seems the deduced target from the extension of the output file (here I imagine its a default "wasm" target) overrides the one specified in GOOS
. And indeed the binary is the same produced with this command without GOARCH
and GOOS
:
$ tinygo build -o hello.wasm hello.go
Is this intended behavior?
This is not directly related, is specifying the output file after the input intended to be invalid (I'm not sure I understand the error)?
$ tinygo build hello.go -o hello.wasm
Build compiles the packages named by the import paths, along with their
dependencies, but it does not install the results. The output binary is
specified using the -o parameter. The generated file type depends on the
extension: ...