Hello! Should one expect to be able to produce components using cargo-component and then instantiate them in Wasmtime from the v13 branch? Is there in general some way that people keep track of compatible versions, and are there generally compatible versions of other tools like cargo-component around each Wasmtime release or is that not always the case? Thanks! :heart:
Extra context for how I ended up asking this question:
Toolchain versions:
> rustc --version
rustc 1.72.0 (5680fa18f 2023-08-23)
> cargo component --version
cargo-component-component 0.1.0 (36c221e 2023-09-07 wasi:134dddc)
Guest world:
package component:guest
world example {
export hello-world: func() -> string
}
Host setup:
let mut config = Config::new();
config.wasm_component_model(true);
let engine = Engine::new(&config).context("Failed to create engine")?;
let component = Component::from_file(&engine, "../guest/target/wasm32-wasi/debug/guest.wasm")
.context("Failed to load guest component")?;
let mut linker = Linker::new(&engine);
let mut table = Table::new();
let mut store = Store::new(
&engine,
MyState {
wasi: WasiCtxBuilder::new().inherit_stdio().build(&mut table)?,
table,
},
);
wasmtime_wasi::preview2::command::sync::add_to_linker(&mut linker)
.context("Failed to set up WASI")?;
let (bindings, _) = Example::instantiate(&mut store, &component, &linker)
.context("Failed to instantiate guest component")?;
Output:
Error: Failed to instantiate guest component
Caused by:
0: import `wasi:io/streams` has the wrong type
1: instance export `write` has the wrong type
2: type mismatch with results
3: expected 0-tuple, found 2-tuple
I assume (from ignorance) that this is because of recent changes to WASI and Wasmtime's implementation. Does that sound about right? Or maybe I just stuffed something up?
the 13 branch has changes to streams that landed in the spec repo as this PR: https://github.com/WebAssembly/wasi-io/pull/45
cargo-component's wasi preview 1 adapter was built prior to those changes, so cargo-component needs an update to include them
i believe there is a way to override what adapter cargo-component uses, but i don't know it off the top of my head, and its a weekend. so, if you can figure out how to feed it the wasi-preview1-component-adapter built from the 13 branch, that ought to fix your problem
Wonderful, thanks! :)
I didn't figure out how to override what adapter cargo-component uses; instead I just did the update in the source. So — for anyone else who finds this and wants to do a similar thing — my steps were:
cargo-component
repo locally.wasmtime
repo locally (don't forget to init submodules!).wasm
file following the existing naming convention under the adapters/
dir. I.e. new subdir with abbreviated wasmtime commit sha, with files named wasi_snapshot_preview1.reactor.wasm
and wasi_snapshot_preview1.command.wasm
inside.WASI_ADAPTER_VERSION
in cargo-component
's build.rs
to point to your new directory.cargo-component
: cargo install --path .
cargo-component
will invalidate the build cache.)Hi Jeff, feel free to put up a PR for updating the adapter; I'll also try to add an option for overriding the adapter tomorrow
PR for adapters bump is here: https://github.com/bytecodealliance/cargo-component/pull/140
Thanks!
thanks jeff!
Last updated: Dec 23 2024 at 13:07 UTC