Any wasm file, whether it's before component embed
or after gets an exit code 0 and no output with wasm-tools validate component asdf.wasm --features component-model
.
The same wasm file thrown at wasm-tools component targets asdf.wit asdf.wasm
(or asdf.embed.wasm) gives me:
error: failed to validate encoded bytes
Caused by:
0: expected a version header for a component (at offset 0xc)
When I use asdf.component.wasm (after component embed
and component new --adapt
) then I get:
# wasm-tools component targets ../wit/asdf.wit asdf.component.wasm
error: failed to validate encoded bytes
Caused by:
0: type mismatch for import `library`
missing import named `wasi:io/error@0.2.0` (at offset 0x1a0cd)
Should validate component
fail a validation check before certain wasm-tools steps or will it always be valid component wasm, even without the metadata and embed, if it's compiled against a WIT?
The WASM component build is working, validate doesn't error or warn, yet I get Invalid input WebAssembly code at offset 4: unknown binary version
when running the component from wasmtime-go.
Anyone have eyes for where I went wrong with my simian kludging together of my first WASM program? I'm happy to contribute to docs and guides in gratitude.
https://github.com/eighty4/learn-wasm-components
https://github.com/bytecodealliance/wit-bindgen/issues/906
Only the Rust API supports components at the moment, as there currently is no C API for the component model for the other languages to bind to
Module
only supports a WebAssembly module, not a component
the error message is a horrible one that needs to be fixed
fixed in wasm-tools, that is; it knows it's a component
Are there commands with wasm-tools where I could inspect a wasm file kinda the way you can dump info about elf headers with a binary?
I was worried this would be the case because wasmtime-go hasn't been updated in over a year.
If Rust is the only platform that runs components, does that mean there's no way with another golang runtime to run a function compiled to WASM? A module means it's just a program that can be run and you have to manually map binary data in and out of the function?
I was waiting for the component model for years so I actually don't know how the OG method works that folks have used for consumer facing products like the Envoy and Istio plugin APIs.
AFAIK the component model is a cross-language agreement on how to pass data between WASM instances or an instance and the host, so a golang runtime would just have to implement that to run components. It just so happens that the bleeding edge of WASM runtimes is in Rust. The "OG method" is to define the data layout yourself. WIT is designed to generate code in the host and client languages to handle that instead of doing it manually.
The component runtimes I know of are Wasmtime (the Rust API), JS (via Node via jco), and Python (via wasmtime-py and bindings like jco). I can confirm that wasmtime-go, while we're still updating it, does not have support for components. Wasmtime's C API does not have support for components yet either.
I made an assumption that if wasmtime-go was using C bindings, they would be C bindings of the Rust library.
Yes wasmtime-go is using the C API of Wasmtime, not the Rust API
Last updated: Dec 23 2024 at 12:05 UTC