Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wasi target overriden by output extension #4614

Closed
Wonshtrum opened this issue Nov 19, 2024 · 2 comments
Closed

Wasi target overriden by output extension #4614

Wonshtrum opened this issue Nov 19, 2024 · 2 comments

Comments

@Wonshtrum
Copy link

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: ...
@dgryski
Copy link
Member

dgryski commented Nov 19, 2024

See also #4447

@dgryski
Copy link
Member

dgryski commented Nov 19, 2024

Duplicate: #4439

@dgryski dgryski closed this as completed Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants