Stream: git-wasmtime

Topic: wasmtime / PR #7728 Add more necessary linkers to wasi-http


view this post on Zulip Wasmtime GitHub notifications bot (Dec 27 2023 at 03:38):

iawia002 opened PR #7728 from iawia002:wasi-http-linker to bytecodealliance:main:

When I attempt to run the hello-wasi-http example using wasmtime 16, I encounter the following error(which did not occur in previous versions):

$ wasmtime serve hello_wasi_http.wasm

Error: import `wasi:cli/environment@0.2.0-rc-2023-12-05` has the wrong type

Caused by:
    0: instance export `get-environment` has the wrong type
    1: expected func found nothing

I realize that this may be related to PR #7597, where we might have trimmed too much "world" to the point where a simple HTTP hello world example cannot run. So, this patch adds some content, and now the example can run successfully:

$ ./target/debug/wasmtime serve hello_wasi_http.wasm

Serving HTTP on http://0.0.0.0:8080/

Related: #7716

view this post on Zulip Wasmtime GitHub notifications bot (Dec 27 2023 at 03:38):

iawia002 requested wasmtime-core-reviewers for a review on PR #7728.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 27 2023 at 03:38):

iawia002 requested fitzgen for a review on PR #7728.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2024 at 15:27):

alexcrichton commented on PR #7728:

Thanks for the PR, but these interfaces are all explicitly missing from the standard proxy world. The wasmtime serve subcommand has an -Scommon flag to enable the interfaces in an opt-in basis. Otherwise though this was an intentional behavior change from https://github.com/bytecodealliance/wasmtime/pull/7597

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2024 at 02:48):

iawia002 commented on PR #7728:

OK, but I'm getting a little confused, I know -Scommon flag will make it work because it adds all the linkers, in other words, can I say wasmtime serve won't work without the -Scommon flag? Since I'm just running the basic hello world example.

but these interfaces are all explicitly missing from the standard proxy world.

So do we count this as an issue? I'm not familiar with this, I can't figure out why the proxy world needs those.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2024 at 18:02):

pchickey commented on PR #7728:

The issue is that the https://github.com/sunfishcode/hello-wasi-http instructions aren't up to date with wasmtime 16, which requires passing in the -Scommon flag. Please file an issue or PR over there to add that command line flag.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2024 at 03:36):

iawia002 commented on PR #7728:

The issue is that the https://github.com/sunfishcode/hello-wasi-http instructions aren't up to date with wasmtime 16, which requires passing in the -Scommon flag. Please file an issue or PR over there to add that command line flag.

Actually, I made some updates based on hello-wasi-http to adapt to wasmtime 16. I updated cargo-component version to 0.6.0 and updated wasi:http/proxy to 0.2.0-rc-2023-12-05, if you use the original hello-wasi-http directly, even if the -Scommon flag is added, it still cannot run (because the wit definition does not match):

wasmtime serve -Scommon hello_wasi_http.wasm
Error: import `wasi:cli/stdout@0.2.0-rc-2023-10-18` has the wrong type

Caused by:
    0: instance export `get-stdout` has the wrong type
    1: expected func found nothing

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2024 at 05:37):

iawia002 edited a comment on PR #7728:

The issue is that the https://github.com/sunfishcode/hello-wasi-http instructions aren't up to date with wasmtime 16, which requires passing in the -Scommon flag. Please file an issue or PR over there to add that command line flag.

Actually, I made some updates based on hello-wasi-http to adapt wasmtime 16. I updated cargo-component version to 0.6.0 and updated wasi:http/proxy to 0.2.0-rc-2023-12-05, if you use the original hello-wasi-http directly, even if the -Scommon flag is added, it still cannot run (because the wit definition does not match):

$ wasmtime serve -Scommon hello_wasi_http.wasm
Error: import `wasi:cli/stdout@0.2.0-rc-2023-10-18` has the wrong type

Caused by:
    0: instance export `get-stdout` has the wrong type
    1: expected func found nothing

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2024 at 06:24):

iawia002 commented on PR #7728:

My code: https://github.com/iawia002/hello-wasi-http/tree/adapt-wasmtime-16
The diff (basically only version and dependency updates): https://github.com/iawia002/hello-wasi-http/commit/8fa967735f40988badf3a473459cb3e4c9cb8595
Compiled wasm file: hello_wasi_http.wasm.zip

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2024 at 16:27):

alexcrichton commented on PR #7728:

It looks like you may be running into versioning issues, so I'd recommend double-checking that the adapter in use and the Wasmtime in use are from the same version. I'll also point out that there's an adapter specific to a proxy which avoids the need for -Scommon

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2024 at 01:58):

iawia002 commented on PR #7728:

I'm using wasmtime 16 and cargo-component 0.6.0 which adapts wasmtime 16 and wasi:http/proxy@0.2.0-rc-2023-12-05 which exactly the same with wit definition in wasmtime 16.

$ wasmtime -V
wasmtime-cli 16.0.0 (6613acd1e 2023-12-20)

So I think I've taken care of versioning issues.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2024 at 16:39):

alexcrichton commented on PR #7728:

Are you still getting an error about wasi:cli/stdout@0.2.0-rc-2023-10-18? If so that means there's a versioning problem somewhere because 2023-10-18 is a more historical version than Wasmtime 16.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 06 2024 at 01:58):

iawia002 commented on PR #7728:

Oops, @alexcrichton I think you misunderstood, @pchickey says I'm encountering this issue due to the https://github.com/sunfishcode/hello-wasi-http not adapting with wasmtime 16, I'm trying to explain to you that I'm not using the original hello-wasi-http example and I did some update to make it adapt with wasmtime 16, but even I make those updates, I'm still encountering the issue in the PR description.

Using https://github.com/sunfishcode/hello-wasi-http, with or without -Scommon flag, we'll encounter this error:

$ wasmtime serve -Scommon hello_wasi_http.wasm
Error: import `wasi:cli/stdout@0.2.0-rc-2023-10-18` has the wrong type

Caused by:
    0: instance export `get-stdout` has the wrong type
    1: expected func found nothing

Using https://github.com/iawia002/hello-wasi-http/tree/adapt-wasmtime-16 which adapts wasmtime 16, with -Scommon flag, it works, but without it, we'll encounter this error in the PR description:

$ wasmtime serve hello_wasi_http.wasm

Error: import `wasi:cli/environment@0.2.0-rc-2023-12-05` has the wrong type

Caused by:
    0: instance export `get-environment` has the wrong type
    1: expected func found nothing

Though it will work with -Scommon flag, I still want to ask the same question from my previous comments:

I know -Scommon flag will make it work because it adds all the linkers, in other words, can I say wasmtime serve won't work without the -Scommon flag? Since I'm just running the basic hello world example.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 08 2024 at 15:19):

alexcrichton commented on PR #7728:

This all boils down to the adapter you're using. If you use the *.reactor.wasm adapter then yes that won't work for wasmtime serve because it's not intended to work with wasmtime serve. If you use *.proxy.wasm then it will work with wasmtime serve because it's intended to work with the subcommand.

What you're basically running into here is difficulties and road bumps in how a component is built. This doesn't have all that much to do with the runtime per se. This is definitely something we need more documentation and guidance on, and we're doing our best on that.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2024 at 02:05):

iawia002 closed without merge PR #7728.


Last updated: Nov 22 2024 at 16:03 UTC