Unknown placeholder import in wasm32-unknown-unknown #822

Open
opened 2025-03-31 04:29:42 -05:00 by dvn8weil · 11 comments
dvn8weil commented 2025-03-31 04:29:42 -05:00 (Migrated from github.com)

Hi,
When i am trying to build my project containing the following uuid dependency :
uuid = {version = "1.16.0", features = ["v4", "js"]}
The .wat file contains these imports including the placeholder import that are creating issue in my usage of the wasm binary.

(import "__wbindgen_placeholder__" "__wbindgen_describe" (func $_ZN12wasm_bindgen19__wbindgen_describe17ha2b0f1d17785f195E (;2;) (type 0)))
  (import "__wbindgen_externref_xform__" "__wbindgen_externref_table_grow" (func $_ZN12wasm_bindgen9externref31__wbindgen_externref_table_grow17hdc9360a44cb6f2f5E (;3;) (type 1)))
  (import "__wbindgen_externref_xform__" "__wbindgen_externref_table_set_null" (func $_ZN12wasm_bindgen9externref35__wbindgen_externref_table_set_null17h2e60a48c28265f6eE (;4;)

Is there something that i am missing here?
Thanks!

Hi, When i am trying to build my project containing the following uuid dependency : `uuid = {version = "1.16.0", features = ["v4", "js"]}` The .wat file contains these imports including the placeholder import that are creating issue in my usage of the wasm binary. ``` (import "__wbindgen_placeholder__" "__wbindgen_describe" (func $_ZN12wasm_bindgen19__wbindgen_describe17ha2b0f1d17785f195E (;2;) (type 0))) (import "__wbindgen_externref_xform__" "__wbindgen_externref_table_grow" (func $_ZN12wasm_bindgen9externref31__wbindgen_externref_table_grow17hdc9360a44cb6f2f5E (;3;) (type 1))) (import "__wbindgen_externref_xform__" "__wbindgen_externref_table_set_null" (func $_ZN12wasm_bindgen9externref35__wbindgen_externref_table_set_null17h2e60a48c28265f6eE (;4;) ``` Is there something that i am missing here? Thanks!
dvn8weil commented 2025-03-31 04:33:12 -05:00 (Migrated from github.com)

Steps to reproduce the issue :

  1. Create a new rust project ,
  2. Add the following to Cargo.toml
[dependencies]
uuid = {version = "1.16.0", features = ["v4", "js"]}
getrandom = {version = "0.2.2", features=["js"]}

[lib]
crate-type = ["cdylib"]
  1. Add usage of uuid such as uuid::Uuid::new_v4()
  2. compile with target as wasm32-unknown-unknown. Run cargo build --target wasm32-unknown-unknown --release.
  3. wasm-tools print target/wasm32-unknown-unknown/release/<library_name>.wasm -o <library_name>.wat
Steps to reproduce the issue : 1. Create a new rust project , 2. Add the following to `Cargo.toml` ``` [dependencies] uuid = {version = "1.16.0", features = ["v4", "js"]} getrandom = {version = "0.2.2", features=["js"]} [lib] crate-type = ["cdylib"] ``` 3. Add usage of uuid such as `uuid::Uuid::new_v4()` 4. compile with target as `wasm32-unknown-unknown`. Run `cargo build --target wasm32-unknown-unknown --release`. 5. `wasm-tools print target/wasm32-unknown-unknown/release/<library_name>.wasm -o <library_name>.wat`
KodrAus commented 2025-04-03 20:59:01 -05:00 (Migrated from github.com)

Hi @dvn8weil 👋 I'm not entirely sure what the issue is here. It doesn't look especially uuid specific. uuid doesn't use getrandom by default anymore, do you still see the issue if you enable the rng-getrandom or rng-rand features of uuid? Keep in mind these are based on getrandom 0.3, and not 0.2.

Are you also building with the latest versions of rustc and wasm-bindgen?

Hi @dvn8weil :wave: I'm not entirely sure what the issue is here. It doesn't look especially `uuid` specific. `uuid` doesn't use `getrandom` by default anymore, do you still see the issue if you enable the `rng-getrandom` or `rng-rand` features of `uuid`? Keep in mind these are based on `getrandom` `0.3`, and not `0.2`. Are you also building with the latest versions of `rustc` and `wasm-bindgen`?
KodrAus commented 2025-05-14 16:07:49 -05:00 (Migrated from github.com)

Just coming back through some triage, I'm not quite sure what happened here, but if it's still an issue please feel free to re-open and we can try digging in deeper.

Just coming back through some triage, I'm not quite sure what happened here, but if it's still an issue please feel free to re-open and we can try digging in deeper.
dvn8weil commented 2025-06-01 07:52:24 -05:00 (Migrated from github.com)

Hi, apologies for the late reply :
I removed the get_random dependency.
Cargo.toml :

[package]
name = "uuid_test"
version = "0.1.0"
edition = "2024"

[dependencies]
uuid = {version = "1.17.0", features = ["v4", "js"]}

[lib]
crate-type = ["cdylib"]

but in the .wasm file , i get after cargo build --target wasm32-unknown-unknown --release , and converting it to .wat file by wasm-tools print target/wasm32-unknown-unknown/release/uuid_test.wasm -o uuid_test1.wat

there is still the placeholder import :
(import "__wbindgen_placeholder__" "__wbindgen_describe" (func $_ZN12wasm_bindgen19__wbindgen_describe17hd20bcaa9ef979b7fE (;2;) (type 3)))

Hi, apologies for the late reply : I removed the `get_random` dependency. `Cargo.toml` : ``` [package] name = "uuid_test" version = "0.1.0" edition = "2024" [dependencies] uuid = {version = "1.17.0", features = ["v4", "js"]} [lib] crate-type = ["cdylib"] ``` but in the .wasm file , i get after `cargo build --target wasm32-unknown-unknown --release` , and converting it to .wat file by `wasm-tools print target/wasm32-unknown-unknown/release/uuid_test.wasm -o uuid_test1.wat` there is still the placeholder import : `(import "__wbindgen_placeholder__" "__wbindgen_describe" (func $_ZN12wasm_bindgen19__wbindgen_describe17hd20bcaa9ef979b7fE (;2;) (type 3)))`
KodrAus commented 2025-06-01 14:41:08 -05:00 (Migrated from github.com)

@dvn8weil What platform are you trying to use your wasm in? And what’s the issue you’re running in to with those imports?

@dvn8weil What platform are you trying to use your wasm in? And what’s the issue you’re running in to with those imports?
dvn8weil commented 2025-06-01 21:43:30 -05:00 (Migrated from github.com)

@KodrAus Hi, I am just compiling the rust project with cargo build --target wasm32-unknown-unknown --release. Therein when i convert the .wasm file into .wat for better readability, it contains (the .wat file) such placeholder imports.
These imports shouldn't be present when using wasm32-unknonwn-unknown compatible dependencies.

I have updated my rustc with all its components, as well wasm-tools.

@KodrAus Hi, I am just compiling the rust project with `cargo build --target wasm32-unknown-unknown --release`. Therein when i convert the .wasm file into .wat for better readability, it contains (the .wat file) such placeholder imports. These imports shouldn't be present when using wasm32-unknonwn-unknown compatible dependencies. I have updated my rustc with all its components, as well wasm-tools.
KodrAus commented 2025-06-02 03:06:38 -05:00 (Migrated from github.com)

Hmm, do you know what the presence of these placeholders implies? Does it mean there’s a call somewhere to a function that isn’t being bindgen’d? It’s a bit tricky to tell exactly where the issue is here or how to fix it. uuid is already used in wasm environments pretty heavily so there must be some missing piece here.

Hmm, do you know what the presence of these placeholders implies? Does it mean there’s a call somewhere to a function that isn’t being bindgen’d? It’s a bit tricky to tell exactly where the issue is here or how to fix it. `uuid` is already used in wasm environments pretty heavily so there must be some missing piece here.
KodrAus commented 2025-06-02 17:28:36 -05:00 (Migrated from github.com)

I'm going to re-open this in case there's something we're doing/not doing here in uuid that's causing these imports to be added. I'm not sure yet whether these imports represent an issue with uuid, or an issue with the use-case. If they're always generated then does wasm-bindgen produce glue code that handles them?

I'm going to re-open this in case there's something we're doing/not doing here in `uuid` that's causing these imports to be added. I'm not sure yet whether these imports represent an issue with `uuid`, or an issue with the use-case. If they're always generated then does `wasm-bindgen` produce glue code that handles them?
dvn8weil commented 2025-06-02 20:38:52 -05:00 (Migrated from github.com)

I think it should be then that these imports will be handled by the runtime environment/medium , such as browser or node.js.
So if uuid with the dependencies as this , is supported by those runtime environments, functions for these imports must be provided by those envs.

I think it should be then that these imports will be handled by the runtime environment/medium , such as browser or node.js. So if uuid with the dependencies as this , is supported by those runtime environments, functions for these imports must be provided by those envs.
KodrAus commented 2025-06-04 16:30:49 -05:00 (Migrated from github.com)

Ok, I've had a fresh look at this, and I believe the problem here is coming from the wasm RNG implementation used by getrandom, which we've also inlined into uuid through its js feature.

Those bindings require a table to work, probably because of their use of Uint8Array. In uuid, we might be able to work around this, since we never need to fill more than 16 bytes of random values. Since we inlined that code I'm not 100% sure what the failure modes it's protecting against are.

Ok, I've had a fresh look at this, and I believe the problem here is coming from the [wasm RNG implementation](https://github.com/rust-random/getrandom/blob/master/src/backends/wasm_js.rs) used by `getrandom`, which we've also inlined into `uuid` through its `js` feature. Those bindings require a table to work, probably because of their use of `Uint8Array`. In `uuid`, we might be able to work around this, since we never need to fill more than 16 bytes of random values. Since we inlined that code I'm not 100% sure what the failure modes it's protecting against are.
KodrAus commented 2025-06-04 17:13:26 -05:00 (Migrated from github.com)

It doesn't look like removing the use of Uint8Array removes those references. You can get rid of them though by configuring uuid to use getrandom via the rng-getrandom feature, and configuring getrandom to use a custom backend, which you can then implement based on whatever your target has available.

It doesn't look like removing the use of `Uint8Array` removes those references. You can get rid of them though by configuring `uuid` to use `getrandom` via the `rng-getrandom` feature, and configuring `getrandom` to use a [custom backend](https://github.com/rust-random/getrandom?tab=readme-ov-file#custom-backend), which you can then implement based on whatever your target has available.
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-uuid-rs/uuid#822
No description provided.