Hello! I am trying to move away from wasm-tools component new
and use cargo component build
instead. I have successfully installed cargo-component
and the build command finished BUT trying to use wasmtime serve
tells me the wasm binary is not a component. After using wasm-tools
with the preview1_reactor everything works just fine .
My example is based on the Spin SDK: https://github.com/fermyon/spin/blob/v2.1/examples/http-rust/src/lib.rs
Sorry for the obvious stupid question but I just would like to understand what can I do to get the most out of the cargo-component
Hi @Timo Stark. I am unfamiliar with the Spin SDK and what it normally is expecting to produce.
If cargo component build
is not producing a component (something that's easily verified with wasm-tools print <path/to/wasm>
to see if it starts with component
), then it's likely that there were no component type information section emitted into the core module output from the Rust toolchain. That can happen if you're not explicitly generating bindings with wit_bindgen::generate
or cargo_component_bindings::generate
and also when not linking in any crate dependencies that similarly didn't include any bindings.
If you'd like to file an issue on the cargo-component
repository with repro steps, I am happy to take a look and see what the problem is.
Thanks Peter! Thats helpful information. I think what you just described is the core issue. I have updated the examples in my Github and guess I will try to find out on how to mod the Cargo.toml
to make thinks work with cargo component
. https://github.com/tippexs/unit-power-spin/tree/main/application
I really don't think this is an issue on your end but would appreciate if you could have a quick look into the gh repo just shared.
Briefly looking at Spin's macro source, it does appear to be invoking wit_bindgen::generate!
under the covers, so I would expect the component type information section to be present in the resulting core module; I'll try to look into this tomorrow as it's a holiday in the States today.
No hurry @Peter Huene .Really appreciate it! I have a working solution using wasm-tools
so this is not super critical. Thanks a lot for your help
Oh I think I spotted the issue
add a [package.metadata.component]
section to your Cargo.toml
and see if cargo component build
now produces a component
Will do. One second
cargo-component
is expecting that section (it's what cargo component new
outputs) to inform the tool that the package should be treated as a component vs. any other package type (e.g. a Rust package that's really meant to be a wasm core module as output)
Ahhh I see. Just created a new one to have a reference. Let me copy this into the other Cargo.toml
Okay great! This generates a component! Thanks. But is there a way to define what reactor it should use? I guess I saw something in the docs. Let me check! Don't want to keep you on this any longer on your free day!
Thanks a lot for your help! This was perfect!
You can specify adapter = "path/to/adapter.wasm"
in the package.medata.component
table
which will override the built-in adapter
Yes ... Just found it in the docs! It woks! Excellent support! Thanks Peter!
As a reference for others. The Cargo.toml
using Fermyon Spin SDK AND cargo component
looks like
[package]
name = "application"
version = "0.1.0"
edition = "2021"
[package.metadata.component]
package = "component:application"
adapter = "./wasi_snapshot_preview1.reactor.wasm"
[lib]
crate-type = [ "cdylib" ]
[dependencies]
anyhow = "1"
http = "0.2.9"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
spin-sdk = "2.1.0"
Timo Stark has marked this topic as resolved.
Last updated: Nov 25 2024 at 19:03 UTC