rylev / wepl

A repl for WebAssembly Components
Apache License 2.0
105 stars 7 forks source link

can't load wasmtime 17 runnable component; type mismatch #14

Closed squillace closed 6 months ago

squillace commented 6 months ago

I compiled a C wasi:http server to wasi-sdk 21 (v0.2.0) and used wasm-tools 1.200.0 (69a397f99 2024-02-15) and wit-bindgen-cli 0.18.0 (3faf486e3 2024-02-13) to build it.

BUT, as I might expect from the readme, wepl thinks there's a types mismatch.

squillace@dellsquill:~/work/squillace/dev-wasm-c/http$ wepl server_0_2_0.component.wasm
Error: could not instantiate component

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

However, per the README I can in fact run it on wasmtime 17.01:

squillace@dellsquill:~$ ./wasmtime-v17.0.1-x86_64-linux/wasmtime serve -Scommon ~/work/squillace/dev-wasm-c/http/server_0_2_0.component.wasm
Serving HTTP on http://0.0.0.0:8080/

and the cargo.toml lists wasmtime 18.01....

I'd love to update this myself....

rylev commented 6 months ago

This is because wepl does not know about the wasi:http/proxy world (nor any other world other than wasi:cli/command). wepl does its best to inspect the input component and stub out all the imports with a simple trapping implementation (i.e., if the import function gets called it just traps), but it does not do the same for resources. The error message you're getting here indicates that the linker does not have an implementation for the fields resource.

What wepl needs is the ability to provide stub implementations for resources as well as functions.

I'm going to close this issue in favor of a new one that more directly indicates this missing feature.