Hi, When I attempt to encode my runtime test wasm for c# with
let component = ComponentEncoder::default()
.module(module.as_slice())
.expect("pull custom sections from module")
.validate(true)
.adapter("wasi_snapshot_preview1", &wasi_adapter)
.expect("adapter failed to get loaded")
.encode()
.expect(&format!(
"module {:?} can be translated to a component",
out_wasm
));
I'm getting error
"C:\\github\\wit-bindgen-csharp\\target\\runtime-tests\\numbers\\csharp-numbers\\csharp-wasm\\csharp-wasm.wasm"
thread 'numbers::run' panicked at 'module "C:\\github\\wit-bindgen-csharp\\target\\runtime-tests\\numbers\\csharp-numbers\\csharp-wasm" can be translated to a component: failed to reduce input adapter module to its minimal size
Caused by:
adapter module does not have export `fd_advise`', tests\runtime\main.rs:695:14
I understand that wasi provides a fd_advise
, is that not the case?
Are you sure you're using the right adapter? The fd_advise
function is present in the adapter provided by Wasmtime, but if you're using a different adapter then you may need to make sure that function is present in the custom adapter
I'm using the one from wit-bindgen-csharp\\target\\debug\\build\\test-artifacts-477de5d9b736cf4f\\out\\wasm32-unknown-unknown/release/wasi_snapshot_preview1.wasm
How do I know from where that originates?
I believe that's project-specific build/configuration options, which I'm not familiar with in this case
Would https://github.com/bytecodealliance/preview2-prototyping/releases/tag/latest by the right place for the latest wit-bindgen?
Guess not quite as there is now a version mismatch
component-type version 2 does not match supported version 3', tests\runtime\main.rs:693:14
Is wit-bindgen already on version 3?
All (?) language toolchains currently generate core modules rather than components. In order to allow a tool like wasm-tools component new
to generate a component from one of these core modules, wit-bindgen embeds type metadata in its generated code. The current version of that metadata is indeed 3
.
Doesn't look like there is a preview3-prototyping repo, where I could download the adpaters Should I build them from source?
Currently the adapters are built as part of the wasmtime repo and are available in the releases: https://github.com/bytecodealliance/wasmtime/releases
Thanks, looks like I will need to export a _start
which I don't have currently perhaps because I wasm-ld
with -Wl,--no-entry
Thought wasm-ld would add that for exec-model=command , but guess not
If you're getting an error about _start
you'll want the *.reactor.wasm
instead of the *.command.wasm
Thanks that gets me to
Error: import `wasi:clocks/wall-clock` has the wrong type
Was a new SDK released?
is that error coming from wasmtime? Or a different runtime?
There's not really releases in a discrete sense for the component model right now so whether or now a new SDK release depends on what you mean, but the answer is probably "yes" for what you're curious about (aka WASI interfaces changed since whatever is generating the error last updated to)
its the wit-bindgen runtime test
oh hm, is it possible to share a reproduction?
I'm not sure, its not my repo. But let me check the wall-clock/now function in the module wasm and the adapter
The adapter does look a bit odd compared to https://github.com/bytecodealliance/wasmtime/blob/8efcb9851602287fd07a1a1e91501f51f2653d7e/crates/wasi/wit/deps/clocks/wall-clock.wit#L37
(import "wasi:clocks/wall-clock" "now" (func $_ZN22wasi_snapshot_preview18bindings4wasi6clocks10wall_clock3now10wit_import17h612125935ddec421E (type 0)))
and
(type (;0;) (func (param i32)))
But maybe that's how it handles the complex type, it returns it via a pointer
yeah that's the canonical abi for returning larger-than-a-primitive types
I think I have this https://github.com/bytecodealliance/wasmtime/issues/6523, the error message is just not that clear, says the type is wrong when it seems like it should be that the type is not found
but with wasmtime_wasi 12 I don't think there is a preview2::wasi
I can attempt to add the whole commands, but it requires a different generic instance of the linker:
error[E0277]: the trait bound `Wasi<numbers::MyImports>: WasiView` is not satisfied
--> tests\runtime\numbers.rs:91:61
|
91 | wasmtime_wasi::preview2::command::add_to_linker(linker);
| ----------------------------------------------- ^^^^^^ the trait `WasiView` is not implemented for `Wasi<numbers::MyImports>`
| |
| required by a bound introduced by this call
|
How was the error above printed? If that's the only output you got then that's a bug in the error printing where it didn't print the full context.
The WASI support for the component model is in a shaky state and you're sort of on your own to get things working right now
it has not been in a "finished" state in wasmtime to-date yet
so it requires chasing down changes between commits and adapter versions and such
Ok, understood. This was printed by cargo test numbers -p wit-bindgen-cli --no-default-features -F csharp
Oh sorry you mean the type mismatch
But the answer is the same, from that command line and appears from the line let (exports, _) = instantiate(&mut store, &component, &linker)?;
I did have it working from a prototype, just not from the runtime test. I can investigate the trait difference and see if there is a way round that
---- numbers::run stdout ----
wasi adapter = "C:\\github\\wit-bindgen-csharp\\target\\debug\\build\\test-artifacts-477de5d9b736cf4f\\out\\wasm32-unknown-unknown/release/wasi_snapshot_preview1.wasm"
"dotnet" "publish" "C:\\github\\wit-bindgen-csharp\\target\\runtime-tests\\numbers\\csharp-numbers\\Numbers.csproj" "-r" "wasi-wasm" "-c" "Debug" "/p:PlatformTarget=AnyCPU" "/p:MSBuildEnableWorkloadResolver=false" "--self-contained" "/p:UseAppHost=false" "-o" "C:\\github\\wit-bindgen-csharp\\target\\runtime-tests\\numbers\\csharp-numbers\\csharp-wasm"
"C:\\github\\wit-bindgen-csharp\\target\\runtime-tests\\numbers\\csharp-numbers\\csharp-wasm\\csharp-wasm.wasm"
testing
add to linker
testwasi add to linker
instantiate
Error: import `wasi:clocks/wall-clock` has the wrong type
Caused by:
0: instance export `now` has the wrong type
1: expected func found nothing
failures:
numbers::run
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 8 filtered out; finished in 57.55s
error: test failed, to rerun pass `-p wit-bindgen-cli --test runtime`
Is the whole output, reading it closer, I see it did also say "expected func found nothing", which could be the underlying cause although it could do with being less terse, or at least a comma, "epxected func, found nothing"
ah ok that's good to know! Just wanted to make sure context wasn't being left out by accident
and yeah the error message here is definitely not great
I have made a bit of progress I think ! I think I need async bindgen macros because I have this error
thread 'numbers::run' panicked at 'must use async instantiation when async support is enabled', C:\Users\scott\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wasmtime-12.0.0\src\component\linker.rs:211:9
The macro is
wasmtime::component::bindgen!(in "tests/runtime/numbers");
Is there a way to make that generate an async instantiate?
Ah, this seems to be a bit of a rabbit hole, I can enable async with
wasmtime::component::bindgen!({
path: "tests/runtime/numbers",
async : true
});
But then it seems all the test methods need to be converted to async?
error[E0195]: lifetime parameters or bounds on method `roundtrip_u8` do not match the trait declaration
--> tests\runtime\numbers.rs:15:20
|
4 | / wasmtime::component::bindgen!({
5 | | path: "tests/runtime/numbers",
6 | | async : true
7 | | });
| | -
| | |
| |__lifetimes in impl do not match this method in trait
| this bound might be missing in the impl
...
15 | fn roundtrip_u8(&mut self, val: u8) -> Result<u8> {
| ^ lifetimes do not match method in trait
Yes everything is async by default with that configuration. You can replace true with a curly braced map or list to only have some functions be async. I forget what the exact syntax is
Ah looks like I'm thinking of a feature of wiggle, not bindgen!
, so let me go add the feature to bindgen!
Ah, yes it seems to just want a bool at present, thanks!
I've opened https://github.com/bytecodealliance/wasmtime/pull/6942 to add new configuration for making some imports sync
Thank you!
Will close this as I think I just need to work aroumd the async exports now
THanks
Scott Waye has marked this topic as resolved.
Last updated: Nov 22 2024 at 16:03 UTC