missing implementation was not found in linker · C#/.net-collaboration

@Joel Dice I've updated to the latest naot and witbind gen packages. Everything is compiling properly but I am not able to run the http example with wasmtime, I am getting.

 wasmtime serve .\bin\Debug\net8.0\wasi-wasm\native\MyApp.wasm --addr 127.0.0.1:3000
Error: component imports instance `wasi:cli/environment@0.2.0`, but a matching implementation was not found in the linker

Caused by:
    0: instance export `get-environment` has the wrong type
    1: function implementation is missing

Any ideas on what I am missing? I thought it might be the wit for cli imports in the linker but got a different error when that ran

James Sturtevant (Aug 15 2024 at 18:02):

looking at the proxy component_type.wit generated by wit-bindgen it seems to have a package wasi:cli@0.2.0 but I don't see the get-environment import. but the final binary has it:

wasm-tools.exe component wit .\bin\Debug\net8.0\wasi-wasm\native\MyApp.wasm
package root:component;

world root {
  import wasi:cli/environment@0.2.0;
  import wasi:cli/exit@0.2.0;

Joel Dice (Aug 15 2024 at 18:12):

Joel Dice (Aug 15 2024 at 18:13):

I don't think there's currently a way to tell the ILC/runtime to stub out and omit wasi:cli stuff, so we have to tell wasmtime to provide it.

James Sturtevant (Aug 15 2024 at 18:15):

that work! what's adding the adding import wasi:cli/environment@0.2.0;? is that the dotnet compiler?

James Sturtevant (Aug 15 2024 at 18:23):

Joel Dice (Aug 15 2024 at 18:29):

Yeah, presumably either the .NET runtime or wasi-libc are pulling those in such that they can't be trimmed away. I'll bet you could stub them out by passing -Wl,--wasi-adapter,proxy as a linker flag.

James Sturtevant (Aug 15 2024 at 18:30):

It would be better to have those not generated right? I guess I should create an issue in dotnet repo to start to track?

Joel Dice (Aug 15 2024 at 18:37):

Well, they should be generated if the application uses environment variables and/or calls exit. Ideally they wouldn't be generated if the application doesn't use such features, I suppose, but I don't know how easy it is to detect that, nor if either the .NET runtime or wasi-libc proactively grabs environment variables just in case the application might need them.

Feel free to open an issue, but we should be careful not to veer to the other extreme and omit imports when the app actually needs them.

James Sturtevant (Aug 15 2024 at 19:01):

ah, ok that make sense. I was discussing that the other day with some folks, how it is detected if something like an env is needed in the runtime and what would happen

Ralph (Aug 16 2024 at 13:04):

good issue to add to that repo -- they either have an answer, or are on default as it's being built (which, understandable)

Mossaka (Joe) (Sep 04 2024 at 17:33):

It tells me that wasi-http/proxy probably needs to import wasi:cli/environment

James Sturtevant (Sep 05 2024 at 15:33):

I don't think wasi-http should import, it isn't needed for the functionality. It would be perferable to have smaller independent functionality and then let the user bring it toget as needed. Ideally the lanaguage compiler could dectect if ENVs/exit are in use and either bring them in or leave them out but maybe that's pretty hard to do and is why its there be default

James Sturtevant (Sep 05 2024 at 15:42):

WASI components import `wasi:cli/environemnt` and `wasi:cli/exit` when not being used · Issue #107405 · dotnet/runtime

problem statement When building a component for wasi:http when running in wasmtime I get the following error: wasmtime serve .\bin\Debug\net8.0\wasi-wasm\native\MyApp.wasm --addr 127.0.0.1:3000 Err...

Scott Waye (Sep 08 2024 at 20:35):

called `Result::unwrap()` on an `Err` value: component imports instance `wasi:io/error@0.2.0`, but a matching implementation was not found in the linker

Caused by:
    0: instance export `error` has the wrong type
    1: resource implementation is missing

Is there an equivalent for -S cli etc but when linking or instantiating components in rust ?

Scott Waye (Sep 08 2024 at 23:43):

    fn type_annotate_wasi<T, F>(val: F) -> F
    where
        F: Fn(&mut T) -> &mut T,
    {
        val
    }
    let wasi_closure = type_annotate_wasi::<HostState, _>(|t| t);
    stdin::add_to_linker_get_host(&mut linker, wasi_closure)?;
    stdout::add_to_linker_get_host(&mut linker, wasi_closure)?;
    stderr::add_to_linker_get_host(&mut linker, wasi_closure)?;
    error::add_to_linker_get_host(&mut linker, wasi_closure)?;
    monotonic_clock::add_to_linker_get_host(&mut linker, wasi_closure)?;
    wall_clock::add_to_linker_get_host(&mut linker, wasi_closure)?;
    tcp::add_to_linker_get_host(&mut linker, wasi_closure)?;
    udp::add_to_linker_get_host(&mut linker, wasi_closure)?;
    random::add_to_linker_get_host(&mut linker, wasi_closure)?;

Stream: C#/.net-collaboration

Topic: missing implementation was not found in linker

James Sturtevant (Aug 15 2024 at 17:37):