Stream: cargo-component

Topic: wasi crate "hello world" not working

Yoshua Wuyts (Feb 26 2024 at 15:46):

I just filed #236 - not sure if I'm possibly holding it wrong? If there's anything I could do to help fix this please let me know - I wouldn't mind having an issue I could fix to contribute to cargo-component!

Peter Huene (Feb 26 2024 at 16:56):

I've added some context to the issue; there is a bug relating to building examples and cargo-component's bindings doesn't appear compatible with the latest wit-bindgen due to some breaking changes in runtime types; i can do a release of cargo-component to update it.

Ryan Levick (rylev) (Feb 26 2024 at 18:30):

I believe I ran into the same (or very similar issue) where cargo component new gave me a project which depended on wit-bindgen 0.19.1 which would fail to compile since the bindings were generated by 0.18. Shouldn't the version generated for the Cargo.toml be matched with the version used by cargo-component?

Peter Huene (Feb 26 2024 at 18:53):

generally it doesn't have to, as changes to the runtime types/functions are less frequently than the bindings generation

Peter Huene (Feb 26 2024 at 18:53):

if we were to fix it so that this doesn't happen again, i'd love to move in the direction of not having a user's Cargo.toml reference wit-bindgen at all

Alex Crichton (Feb 26 2024 at 18:54):

I wrote up some longer form thoughts but I agree that wit-bindgen should not have to match in cargo component as that'll create a lot of usability headaches (like this) in the future

Alex Crichton (Feb 26 2024 at 18:54):

removing the wit-bindgen dep entirely might be kind of hard though

Peter Huene (Feb 26 2024 at 18:54):

it would also prevent such problems where users use the wit-bindgen rust CLI and reference a mismatched wit-bindgen in their Cargo.toml

Alex Crichton (Feb 26 2024 at 18:55):

if we could define cabi_realloc in a reasonable way I think we could delete the crate entirely

Alex Crichton (Feb 26 2024 at 18:55):

modulo bitflags! I suppose

Peter Huene (Feb 26 2024 at 18:58):

in the mean time, i'll update the wit-bindgen dependency of cargo-component, fix componentization to not require [package.metadata.component] (i.e. key off of the custom section), and fix examples (and other target crate-types) not being treated as bins when they should be for the purpose of adapter selection

Alex Crichton (Feb 26 2024 at 19:00):

you know maybe this can be the wasm32-wasip2 target in Rust

Alex Crichton (Feb 26 2024 at 19:00):

it's got cabi_realloc built-in for us

Alex Crichton (Feb 26 2024 at 19:00):

then wit-bindgen doesn't have to do anything

Alex Crichton (Feb 26 2024 at 19:01):

ok yeah I'm gonna go change wit-bindgen to rely on nothing from the crate but macro things and cabi_realloc

Peter Huene (Feb 26 2024 at 19:05):

hmm; the logic for componentization should be either 1) the [package.metadata.component] section is present, as the module might not have a component type in the case of default "bin" components that don't use bindings and expect a preview1 command adapter for fn main or 2) the module has a component-type CS

Alex Crichton (Feb 26 2024 at 19:06):

that sounds reasonable to me yeah

Alex Crichton (Feb 26 2024 at 19:06):

although the custom section only needs to have component-type as a prefix

Peter Huene (Feb 26 2024 at 19:06):

right

Peter Huene (Feb 26 2024 at 19:09):

it seems that the default bin project does include empty bindings with an "empty" component type, so it works even without a [package.metadata.component] section, so never mind

Peter Huene (Feb 26 2024 at 19:09):

just the custom section presence should work

Alex Crichton (Feb 26 2024 at 19:21):

oh nice

Alex Crichton (Feb 26 2024 at 20:55):

I've implemented https://github.com/bytecodealliance/wit-bindgen/pull/868 for everything except cabi_realloc

Yoshua Wuyts (Mar 05 2024 at 17:10):

Now that a new version of cargo-component has been published; does that also mean that we need to publish a new version of the wasi crate with the updated bindings?

Yoshua Wuyts (Mar 05 2024 at 17:12):

I was just trying out the new release of cargo-component, and am getting this error:

Error: failed to run main module `/Users/yosh/Code/wasm-http-tools/target/wasm32-wasi/debug/examples/main.wasm`

Caused by:
    0: import `wasi:http/types@0.2.0` has the wrong type
    1: instance export `fields` has the wrong type
    2: expected resource found nothing

This looks like WIT imports, but all my imports are going through the wasi crate. So I suspect it's probably something there?

Yoshua Wuyts (Mar 05 2024 at 17:13):

Oh lol, now seeing https://github.com/bytecodealliance/wasi/pull/80 is up

Yoshua Wuyts (Mar 05 2024 at 17:13):

Yeah okay, that would make sense!

Alex Crichton (Mar 05 2024 at 17:20):

Is that error perhaps a missing -S http flag to wasmtime run?

Alex Crichton (Mar 05 2024 at 17:20):

(by default the CLI doesn't give access to wasi-http)

Yoshua Wuyts (Mar 05 2024 at 17:20):

oh lol, yeah that would probably do it :sweat_smile:

Yoshua Wuyts (Mar 05 2024 at 17:20):

I definitely forgot the flag

Yoshua Wuyts (Mar 05 2024 at 17:23):

Oh strange, if I do:

cargo component run --example main -- -S http=y

I still get the same error

Yoshua Wuyts (Mar 05 2024 at 17:23):

I mean; now that I'm realizing we still need to bump the wasi crate to the latest wasm-bindgen output it makes sense to me that it fails

Yoshua Wuyts (Mar 05 2024 at 17:24):

Curious how it's that error though

Alex Crichton (Mar 05 2024 at 17:24):

I don't know whether that command passes the -S flag to wasmtime or the wasm binary itself, but I would guess the latter

Alex Crichton (Mar 05 2024 at 17:24):

(others might know for sure though)

Alex Crichton (Mar 05 2024 at 17:25):

In theory wasi I don't think should need an update, but I haven't checked on that in a bit

Yoshua Wuyts (Mar 05 2024 at 17:25):

In another example, this compiled correctly for me:

cargo component run -- -S nn=y  # Run our app

maybe there's something different when paired with --example ?

Yoshua Wuyts (Mar 05 2024 at 17:26):

Alex Crichton said:

In theory wasi I don't think should need an update, but I haven't checked on that in a bit

oh I see!

Yoshua Wuyts (Mar 05 2024 at 17:26):

haha, yeah don't worry about debugging this right now over Zulip

Yoshua Wuyts (Mar 05 2024 at 17:26):

I'll spend a bit more time poking at it to see what is causing the failure

Yoshua Wuyts (Mar 05 2024 at 17:27):

If I can't figure it out I'll bring back something more detailed

Yoshua Wuyts (Mar 05 2024 at 17:27):

(appreciate the help though!)

Peter Huene (Mar 05 2024 at 18:09):

The args passed after -- are for the guest program and not the runner. You may use CARGO_TARGET_WASM32_WASI_RUNNER to set the runner to use or target.wasm32-wasi.runner in .cargo/config.toml

Peter Huene (Mar 05 2024 at 18:10):

although it appears we may not be respecting CARGO_TARGET_WASM32_WASI_RUNNER like we should be

Peter Huene (Mar 05 2024 at 18:10):

.cargo/config.toml should work though

Peter Huene (Mar 05 2024 at 18:11):

oh never mind, the cargo-config crate handles sourcing from the environment variable for us

Peter Huene (Mar 05 2024 at 18:11):

both should work

Peter Huene (Mar 05 2024 at 18:17):

if you set CARGO_COMPONENT_LOG=debug, you'll see output for the runner it ends up spawning

Last updated: Dec 06 2025 at 06:05 UTC