Stream: wit-bindgen

Topic: Following README emits broken wasm

Surma (Feb 17 2023 at 11:11):

I suspect that is a wasm-tools issue, but I thought I'd ask anyway. I was following the README example in the wit-bindgen repo and (apart from some minor fixups) I ended up with a valid wasm file for the component. I downloaded the WASI preview adapter wasm as well (also valid wasm). But once I linked them using wasm-tools, I get a Wasm file with an invalid magic number that is also not accepted by wasmtime.

$ wasm-tools component new ./target/wasm32-wasi/debug/wit.wasm -o comp.wasm --adapt ./wasi_snapshot_preview1.wasm

$ file comp.wasm
comp.wasm: WebAssembly (wasm) binary module version 0x1000c

$ wasmtime run comp.wasm
Error: failed to run main module `comp.wasm`

Caused by:
    0: failed to parse WebAssembly module
    1: Invalid input WebAssembly code at offset 4: unknown binary version

Am I holding it wrong or is this a bug?

Alex Crichton (Feb 17 2023 at 14:29):

You likely need to build wasmtime from source to get an updated decoder

Surma (Feb 17 2023 at 14:45):

So 0x1000c is intentional, yea?

Surma (Feb 17 2023 at 14:46):

... In retrospect, I probably should have tried wasm-tools parse, which works just fine

Alex Crichton (Feb 17 2023 at 15:03):

yeah that's the expected current version

Surma (Feb 17 2023 at 15:23):

So I built wasm-tools with -F component and built wasmtime with -F component-model, which has slightly altered the error message, but it is still failing to run the module:

wasmtime run --wasm-features component-model ./comp.wasm
Error: if you're trying to run a precompiled module, pass --allow-precompiled

Caused by:
    0: failed to parse WebAssembly module
    1: Unsupported feature: component model

Ramon Klass (Feb 17 2023 at 15:25):

juust to make sure since I made that error a few days ago and somebody helped me: are you certain you use the latest git versions of everything? Cargo.lock remembers which revision it used and won't let cargo fetch newer code unless you delete the lockfile

Surma (Feb 17 2023 at 15:27):

I’m specifying full paths to my local build artifacts, so I don’t think that’s the issue here. But let me triple-check

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

I think this only applies if you depend directly on git in Cargo.toml, right

Alex Crichton (Feb 17 2023 at 15:45):

that error message indicates you're not passing --wasm-features component-model to the runtime of wasmtime, but you clearly are, so I'm not entirely sure

Alex Crichton (Feb 17 2023 at 15:45):

it may be that enabling the component-model feature of the CLI didn't work or the wasmtime executable you're using isn't the one that you built?

Surma (Feb 17 2023 at 16:02):

Yeah that’s why I’m so confused. I am specifying the full path to the wasm binary:

~/src/github.com/bytecodealliance/wasmtime/target/release/wasmtime run --wasm-features component-model ./comp.wasm

Surma (Feb 17 2023 at 16:03):

The CLI even lists the component model in the help

$ ~/src/github.com/bytecodealliance/wasmtime/target/release/wasmtime run --help                                                                                   130 ↵
wasmtime-run
Runs a WebAssembly module

USAGE:
    wasmtime run [OPTIONS] <MODULE> [--] [ARGS]...

... bla bla bla ...

Supported values for `--wasm-features`:

all               enables all supported WebAssembly features
bulk-memory       enables support for bulk memory instructions
multi-memory      enables support for the multi-memory proposal
multi-value       enables support for multi-value functions
reference-types   enables support for reference types
simd              enables support for proposed SIMD instructions
threads           enables support for WebAssembly threads
memory64          enables support for 64-bit memories
component-model   enables support for the component model            <--- !!

... bla bla bla

Alex Crichton (Feb 17 2023 at 16:09):

hm that may be a bug somewhere else then, can you share the component you have?

Surma (Feb 17 2023 at 16:12):

Literally the stuff created by following the README. Here’s the files that I am using:

• comp.wasm (output of wasm-tools component new...)
• wasi_snapshot_preview1.wasm
• wit.wasm (output of cargo build --target=wasm32-wasi)

Alex Crichton (Feb 17 2023 at 16:17):

oh sorry I remember now, wasmtime run doens't have support for components

Alex Crichton (Feb 17 2023 at 16:17):

and that's a bad error message I think of compiling a component with a Module

Surma (Feb 17 2023 at 16:50):

Oh, I am just now grasping that wasmtime-the-crate can run components, but wasmtime-the-cli can not (yet). So I guess I have to build my own thing for now

Alex Crichton (Feb 17 2023 at 16:54):

yeah this is largely blocked on more WASI support and stabilization

Alex Crichton (Feb 17 2023 at 16:55):

the work in the preview2-prototyping repository will eventually move into the wasmtime repository and there'll be a similar set up to wasi-common

Alex Crichton (Feb 17 2023 at 16:55):

and once there's support for WIT-defined WASI APIs then we'll add CLI support

Mikkel Mørk Hegnhøj (Jul 07 2023 at 10:05):

@Alex Crichton - Is this still the case "wasmtime run doens't have support for components"

Mikkel Mørk Hegnhøj (Jul 07 2023 at 10:05):

I don't see the feature in wasmtime run --help

Lann Martin (Jul 07 2023 at 12:57):

Yes, that is still the case. The preview2 implementation still ongoing - I'm guessing CLI support wouldn't come until that is (more) complete.

Alex Crichton (Jul 07 2023 at 15:09):

Yes wasmtime doesn't currently support components in the CLI, and that'll get enabled when preview2 support is ready

Last updated: Dec 23 2024 at 12:05 UTC