wasm-bindgen: Error "cannot import from modules (`env`)" in complex code.

Describe the Bug and Steps to Reproduce

First of all, an apology because I’ve been unable to make a shorter program that shows this issue: it only happens when I compile the full program.

When building my wasm program RAZE with this command and the latest wasm-bindgen:

$ cargo update
$ wasm-pack build --no-typescript --target no-modules --release

It gives the following error:

error: cannot import from modules (env) with --no-modules

Changing to --target web it does build, but it emits this line into the generated JS:

import * as __wbg_star0 from 'env';

that breaks the runtime. If I remove any reference to the env module (and rework all my JS to work with modules) it works nice, which proves that the env module, whatever it is, is not actually needed.

NOTE: I’ve patched the wasm-opt bundled with wasm-pack with wasm-opt version 93, because the bundled one (version 90 I think) crashes.

Expected Behavior

The env module should not be needed.

What causes the env reference.

Disassembling the .wasm file in directory target, I find this line:

 (import "env" "_ZN4core9panicking18panic_bounds_check17h95b04dd9865918b6E" (func $_ZN4core9panicking18panic_bounds_check17h95b04dd9865918b6E (param i32 i32 i32)))

which is weird because this function is actually defined inside the wasm itself, not externally.

Even weirder, if I comment out the call to f32::sin() in this line, the problem disappears. although the function panic_bounds_check still exists in the wasm (no env though).

I’ve tried extracting this whole module to a simpler project, but then the problem simply does not happen.

Versions used:

  • rustc 1.44.0-beta.4 or 1.45.0-nightly (a74d1862d 2020-05-14)
  • wasm-pack 0.9.1
  • wasm-bindgen 0.2.62 (d896446ed)
  • wasm-opt 93

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 3
  • Comments: 16 (10 by maintainers)

Commits related to this issue

Most upvoted comments

@MatthewHerbst My understanding is that this is basically the wasm-bindgen version of “undefined symbol when linking”. I ran into it when playing with a C dependency that tried calling a function that it expected the environment to provide.

If you’re not doing anything fancy in your own code, most likely one of your dependency crates isn’t “wasm32-unknown-unknown compatible”, and you’ll first have to narrow down which one that is. Unfortunately, I’m not aware of any particularly clever way to do that.

After at least an hour of bisecting, I narrowed it down to the following package update:

Updating parking_lot_core v0.8.0 -> v0.8.2

and to be more precise the problem is also exhibited in v0.8.1

Updating parking_lot_core v0.8.0 -> v0.8.1

Which has the following changelog:

  • Removed deprecated CloudABI support.
  • Fixed build on wasm32-unknown-unknown.
  • Relaxed dependency on smallvec.

It seems like a good chance this is related to https://github.com/Amanieu/parking_lot/pull/265

I am having the same issue as @kellpossible, but parking_lot is not a dependency in my tree at all.

My issue is when targeting web. Specifically, the generated .js file has the line import * as __wbg_star0 from 'env'; at the top, and then in the init function does imports['env'] = __wbg_star0;. When trying to load the script on an HTML page I get the error Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../".

Build command: wasm-pack build --target web --release

I have all optimizations and such turned off. I’ve tried enabling them in different combinations based on advice in this and other threads but nothing has worked so far.

[package.metadata.wasm-pack.profile.release]
# wasm-opt = true

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

[profile.release]
# lto = true
# opt-level = "s"
# opt-level = "z"
# panic = "abort"
$ rustup show
...
active toolchain
----------------

nightly-x86_64-apple-darwin (default)
rustc 1.60.0-nightly (89b9f7b28 2022-01-10)