search

bytecodealliance / wasmtime-go

Go WebAssembly runtime powered by Wasmtime
https://pkg.go.dev/github.com/bytecodealliance/wasmtime-go
Apache License 2.0
767 stars 76 forks source link

Hosting WASM component error `Invalid input WebAssembly code at offset 4: unknown binary version` #215

Closed eighty4 closed 4 months ago

eighty4 commented 4 months ago

I followed the creating a component instructions on this project's README.md to the best of my ability. I have this error from wasmtime-go when calling wasmtime.NewModuleFromFile:

failed to parse WebAssembly module

Caused by:
    Invalid input WebAssembly code at offset 4: unknown binary version

Using wasmtime.NewModuleDeserializeFile gave me an invalid elf header error so I switched to wasmtime.NewModuleFromFile. wasm-tools validate does not source any warnings or errors.

This is my first time working with WASM and don't know any debugging techniques for inspecting a WASM binary. The code and build steps that got me here is hosted at https://github.com/eighty4/learn-wasm-components.

Any direction would be greatly appreciated!

tinygo version 0.31.2 darwin/amd64 (using go version go1.22.1 and LLVM version 17.0.1) go version go1.22.1 darwin/amd64 wasm-tools 1.201.0 wit-bindgen-cli 0.22.0

and for building wasm-tools and wit-bindgen-cli

rustc 1.77.0 (aedd173a2 2024-03-17)

alexcrichton commented 4 months ago

Thanks for the report! I've transferred this issue to the wasmtime-go repository rather than wit-bindgen.

What you're running into here is that wasmtime-go doesn't support components. Modules and components are different things so the module constructors don't support components (and vice versa). Regardless the error messages need to be improved here.

alexcrichton commented 4 months ago

Can you additionally clarify what version of wasmtime-go you were using?

eighty4 commented 4 months ago

1.0.0

I sort of expected this error because wasmtime-go hadn't seen a release in a year.

I'm curious, if the main wasmtime repository is Rust, why doesn't wasmtime-c and wasmtime-go depend on a C library built from the Rust project so features are delivered uniformly?

Also, where is the wasmtime C library on GitHub?

alexcrichton commented 4 months ago

Ah ok yes 1.0.0 is quite old at this point. Can you clarify where you're seeing that says that wasmtime-go hasn't released in a year? I just a few days ago published 19.0.0, but I'm no gopher myself so I may be doing things wrong or forgetting something.

Also both the C API and the Go API are based on the same Rust library providing a C API. The Rust wasmtime crate is not the same as the C API, however, which is why the Rust and C APIs differ.

The Wasmtime C library is located at crates/c-api in the wasmtime repository.

eighty4 commented 4 months ago

Go packages can be a wonky thing. If you just go to https://pkg.go.dev/github.com/bytecodealliance/wasmtime-go the version declared is 1.0.0 but it then says at the top that the latest version is v19. If you view either page for 1.0.0 or v19 they're both tagged as latest. I get confused easily but I don't think this one is on me.

eighty4 commented 4 months ago

The implication of this mismatch on pkg.go.dev, is that go get github.com/bytecodealliance/wasmtime-go@latest will install 1.0.0.

It almost looks like v19, based on url patterns with other packages and subpackages, might be published as a subpackage of the 1.0.0 wasmtime-go.

eighty4 commented 4 months ago

And verified, that is the case.

go get github.com/bytecodealliance/wasmtime-go@v19
go: github.com/bytecodealliance/wasmtime-go@v19: no matching versions for query "v19"
go get github.com/bytecodealliance/wasmtime-go/v19
go: downloading github.com/bytecodealliance/wasmtime-go/v19 v19.0.0
go: added github.com/bytecodealliance/wasmtime-go/v19 v19.0.0

Versions since 1.0.0 have been published as subpackages and not resolvable by the package name wasmtime-go.

alexcrichton commented 4 months ago

Do you know if there's something I should be doing different about publishing? Or anything that can be done to improve the situation here? I fear I'm not enough of a gopher myself to know what to do

eighty4 commented 3 months ago

Tagging the version should be the only thing that needs to update. Not sure what's happened. I inquired on Discord and found out that this is the expected behavior. Golang major versions are isolated and @latest will only ever install 1.X.X, any major version after 1 has to be explicit.

That seems so counter intuitive and I can't believe I've used Golang for years without noticing that nuance. wasmtime-go/v19 would have to be explicit and that was a misunderstanding on my part.

What if you have a subpackage in wasmtime-go that just happens to be called v20? Anyways, sorry for the noise.