unknown import: `__wbindgen_placeholder__::__wbindgen_cb_drop` has not been defined

[jp4g]

Hello,

I am trying to build a package halo2_backend I am working on and import it into javascript.

I can build the package with cargo build --lib --release --package noir_halo2_backend_pse --target wasm32-wasi. However, when I try to initialize using wasmer-js or wasi-js, or if I try to use wasmtime by the cli, it always produces the same error:

 > wasmtime target/wasm32-wasi/release/noir_halo2_backend_pse.wasm
Error: failed to run main module `target/wasm32-wasi/release/noir_halo2_backend_pse.wasm`

Caused by:
    0: failed to instantiate "target/wasm32-wasi/release/noir_halo2_backend_pse.wasm"
    1: unknown import: `__wbindgen_placeholder__::__wbindgen_cb_drop` has not been defined

I've tried removing as many references to wasm-bindgen in a separate branch, including sub-dependencies, but have not progressed. Any suggestions on how I debug this issue would be greatly appreciated!

[jp4g]

Edit: I got it to compile by removing reqwest, but this neuters the functionality. New request for help: How do I get the reqwest functionality without breaking wasi?

[landonxjames]

I have a similar issue, although my error is:

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

Caused by:
    0: failed to instantiate "./wasitest.wasm"
    1: unknown import: `./wasitest.rustc_bg.js::__wbindgen_string_new` has not been defined

Haven't traced it down to a particular dependency yet, but thats my next step. Would be ideal if this could be a compile time error (with some identifying information about what exactly introduces the issue) instead of a runtime error.

[pchickey]

Those symbols are coming from bindings created by the wasm-bindgen crate. wasm-bindgen is not compatible with WASI. wasm-bindgen is intended to be used with those imports implemented in javascript, instantiating Wasm inside a JS engine (web browsers, nodejs, etc).

They are not implemented by wasmtime, and they won't be.

[landonxjames]

I think the confusion, at least on my end, comes from the fact that this .wasm file was generated by cargo wasi which is owned by the Bytecode Alliance (so presumably complies to the WASI standard), and does run a wasm-bindgen step as part of its compilation

[pchickey]

Sorry that tripped you up. That README was written in 2019 when wasm-bindgen and the ideas of interface types were radically different. Its use of wasm-bindgen is super out of date at this point, the upstream wasm-bindgen has moved on and (as far as I can tell) eliminated that obsolete interface types implementation. wasm-bindgen is a rustwasm group project, which isn't part of the Bytecode Alliance. So, we should probably remove that functionality from cargo-wasi and its docs, when someone gets a chance. cc @alexcrichton

In the meantime, the name "interface types" has been subsumed by "component model". The term "interface types" only lives on in the .wit file extension, which is mostly because that extension had been reserved back in the interface types days and it seemed appropriate enough for use.

[alexcrichton]

Thanks for the heads up, I've opened an issue about archiving cargo wasi and updating the README since that tool in general shouldn't be used for WASI any more.