Stream: wit-bindgen

Topic: rust-guest-wasi

Lucas Clerisse (Feb 12 2023 at 09:25):

Hi folks, thanks for the amazing recent work done on bindgen.

I'm experimenting using the latest version and keep getting the same error when trying to use wasm-tools to turn my core module into a component.

$ wasm-tools component new target/wasm32-wasi/debug/hello_world.wasm --adapt wasi_snapshot_preview1.wasm

Error: decoding custom section component-type:wasi

Caused by:
    unsupported component version: 0xb (at offset 0x0)

I've used the polyfills as mentionned on the README, tried compiling polyfills from upstream as well. My*.wit is the following:

interface handler {
  record cloud-event {
    id: string,
    source: string,
    specversion: string,
    typ: string,
  }

  handler: func(e: cloud-event) -> cloud-event
}

default world function {
  export handler: self.handler
}

And the according guest module:

wit_bindgen_guest_rust::generate!({
    world: "function",
    path: "wit/function.wit"
});

struct Function;

impl handler::Handler for Function {
    fn handler(_e: handler::CloudEvent) -> handler::CloudEvent {
        handler::CloudEvent {
            id: "1234".to_string(),
            typ: "message".to_string(),
            source: "function_name".to_string(),
            specversion: "v2".to_string(),
        }
    }
}

export_function!(Function);

The above module compiles without any issue using wasm32-wasi. Would be greatful if you had any directions to point me, been stuck on this for a few hours. Could it be that the wasm-tools i'm using is too upstream and polyfills behind?

Ramon Klass (Feb 12 2023 at 17:27):

fwiw I get the same error, I think as you said that this is a version conflict, but I don't know what to upgrade or downgrade

Peter Huene (Feb 12 2023 at 19:34):

I believe if you use the absolute latest in main for wasm-tools, wit-bindgen, and wasmtime, it should get you the same supported binary format version. There's been changes to what's supported in the binary format for components and when that happens we've been rev'ing a version number in the header to trigger this error up front.

Peter Huene (Feb 12 2023 at 19:35):

there's one more big change on the horizon (resources) before the tools settle down and we get some stability here (finally)

Peter Huene (Feb 12 2023 at 19:35):

there is also a plan to publish what works with what (and perhaps some docker images) to make using these things better while there still is flux

Ramon Klass (Feb 12 2023 at 19:37):

that would be very helpful, right now it's rather hard to find out which part is outdated, and I thought I was sure I use git for all the wasm related dependencies

Lucas Clerisse (Feb 13 2023 at 03:58):

Ramon Klass said:

that would be very helpful, right now it's rather hard to find out which part is outdated, and I thought I was sure I use git for all the wasm related dependencies

Try deleting your Cargo.lock, otherwise you'll never get the latest upstream. @Peter Huene thanks for you suggestion, I think I've tried using all upstreams but there's a possibility I made a mistake somehwere. I'll try again after work tonight, appreciate the help.

Mossaka (Joe) (Feb 16 2023 at 23:33):

Just for your reference the latest version if 0xc

Daniel Macovei (Feb 17 2023 at 17:06):

After more fiddling, I've found that I can get this to work only if I use wasi_snapshot_preview1.command.wasm rather than wasi_snapshot_preview1.wasm for my adapter module, which only works on a .main.rs rather than a lib, in case any of you are still experiencing this

Last updated: Nov 22 2024 at 17:03 UTC