Error "cannot import from modules (`env`)" in complex code. #2160

rodrigorc · 2020-05-26T15:25:40Z

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 (d896446)
wasm-opt 93

The text was updated successfully, but these errors were encountered:

alexcrichton · 2020-05-26T15:41:02Z

The fact that that bounds check is coming up is a bug in compiler-builtins. I don't think that this is a bug in wasm-bindgen?

rodrigorc · 2020-05-26T16:20:40Z

@alexcrichton I think that the particular function panic_bounds_check may be a red herring. If I comment out the call to f32.sin() the reference to env disappears, but the calls to core::panicking::panic_bounds_check() are still there.
It still may be a bug in compiler-builtins or maybe in the wasm-unknown-unknown backend?

rodrigorc · 2020-05-26T18:52:57Z

Rustc 1.43.1 does not show the bug, so I assume it is a bug in the wasm backend for 1.44.0-beta.

I'm so used to the beta not failing that I forget there is a stable... Should this bug be closed here and reopened elsewhere?

alexcrichton · 2020-05-26T20:07:36Z

It's still useful to try to narrow down and figure out where the issue is I think, but yeah it may be best to close this one and figure out best where to open it.

rodrigorc · 2020-05-28T10:34:59Z

I don't know, I have skimmed the source code of Rustc, Coreutils, and the LLVM backend for wasm, and I didn't find anything relevant. If you think this bug is better suited anywhere else, I'll close it and reopen a copy there, but where?

alexcrichton · 2020-05-28T14:21:20Z

I'd recommend first trying to reduce this to a bite-sized test case. That needs to be done first before reporting an issue.

rodrigorc · 2020-05-28T16:06:49Z

Ok, I managed to reduce it a lot. The funny thing was that wasm-pack does some heavy dead-code pruning even in debug mode, so as soon as I removed key lines, the problem disappeared.

This minimum program reproduces the issue:

`Cargo.toml`

[package]
name = "wasm-env-issue"
version = "0.1.0"
edition = "2018"

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

[profile.release]
lto = true
panic = "abort"

[dependencies]
wasm-bindgen = "0.2.55"

`src/lib.rs`

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn wasm_sin(key: i32) -> i32 {
    (key as f32).sin() as i32
}

Command to compile, remember that the issue happens in beta and nightly only:

wasm-pack build --no-typescript --target no-modules

If I switch to lto=false the problem dissapears, which I'm sure it is a good clue, but I cannot interpret.
Also interesting is that f32::sin and f32::cos show the issue, but other functions such as f32::asin do not.

alexcrichton · 2020-05-29T17:11:40Z

Ok bisection shows that this is a regression from rust-lang/rust#70846, and I'll work on fixing this at rust-lang/compiler-builtins#360. This isn't wasm-bindgen-specific, though. Mind opening an issue on the rust-lang/rust repository for this?

rodrigorc · 2020-05-29T20:33:24Z

Of course! here it is. I'm closing this now, I hope it is the proper procedure...
@alexcrichton Thank you so much for your attention!

… 'env' rustwasm/wasm-bindgen#2160 rust-lang/rust#72758

kellpossible · 2021-01-11T11:41:17Z

I'm having a very similar issue on Rust 1.49, edit: I'm also getting the same problem on 1.48, so it's not necessarily related to the compiler version

kellpossible · 2021-01-11T12:37:57Z

I now have a new

import * as __wbg_star0 from 'env';

in the generated module javascript file from wasm-pack.

This problem started occurring when I applied the following cargo update to my project:

    Updating addr2line v0.13.0 -> v0.14.1
    Updating anyhow v1.0.33 -> v1.0.38
    Updating arrayvec v0.5.1 -> v0.5.2
    Updating backtrace v0.3.53 -> v0.3.55
    Updating bit-vec v0.6.2 -> v0.6.3
    Updating byteorder v1.3.4 -> v1.4.2
    Updating bytes v0.5.6 -> v1.0.0
    Removing cloudabi v0.1.0
    Updating ctor v0.1.16 -> v0.1.17
    Updating eyre v0.6.1 -> v0.6.5
    Updating find-crate v0.6.1 -> v0.6.3
    Updating futures v0.3.6 -> v0.3.9
    Updating futures-channel v0.3.6 -> v0.3.9
    Updating futures-core v0.3.6 -> v0.3.9
    Updating futures-executor v0.3.6 -> v0.3.9
    Updating futures-io v0.3.6 -> v0.3.9
    Updating futures-macro v0.3.6 -> v0.3.9
    Updating futures-sink v0.3.6 -> v0.3.9
    Updating futures-task v0.3.6 -> v0.3.9
    Updating futures-util v0.3.6 -> v0.3.9
    Updating getrandom v0.1.15 -> v0.1.16
    Updating gimli v0.22.0 -> v0.23.0
    Updating heck v0.3.1 -> v0.3.2
    Updating http v0.2.1 -> v0.2.3
    Updating indenter v0.3.0 -> v0.3.2
    Updating indexmap v1.6.0 -> v1.6.1
    Updating instant v0.1.7 -> v0.1.9
    Updating intl_pluralrules v7.0.0 -> v7.0.1
    Updating itoa v0.4.6 -> v0.4.7
    Updating js-sys v0.3.45 -> v0.3.46
    Updating libc v0.2.79 -> v0.2.82
    Updating lock_api v0.4.1 -> v0.4.2
    Updating log v0.4.11 -> v0.4.13
    Updating memchr v2.3.3 -> v2.3.4
    Updating num-integer v0.1.43 -> v0.1.44
    Updating num-traits v0.2.12 -> v0.2.14
    Updating object v0.21.1 -> v0.22.0
    Updating once_cell v1.4.1 -> v1.5.2
    Updating parking_lot v0.11.0 -> v0.11.1
    Updating parking_lot_core v0.8.0 -> v0.8.2
    Updating pin-project-lite v0.1.10 -> v0.2.4
    Updating ppv-lite86 v0.2.9 -> v0.2.10
    Updating proc-macro-hack v0.5.18 -> v0.5.19
    Updating quote v1.0.7 -> v1.0.8
    Updating regex v1.4.0 -> v1.4.3
    Updating regex-syntax v0.6.19 -> v0.6.22
    Updating rustc-demangle v0.1.17 -> v0.1.18
    Updating serde v1.0.116 -> v1.0.118
    Updating serde_derive v1.0.116 -> v1.0.118
    Updating serde_json v1.0.58 -> v1.0.61
    Updating sharded-slab v0.0.9 -> v0.1.1
    Updating smallvec v1.4.2 -> v1.6.1
    Updating syn v1.0.44 -> v1.0.58
    Updating thiserror v1.0.21 -> v1.0.23
    Updating thiserror-impl v1.0.21 -> v1.0.23
    Updating thread_local v1.0.1 -> v1.1.0
    Updating time v0.1.44 -> v0.1.43
    Updating toml v0.5.7 -> v0.5.8
    Updating tracing v0.1.21 -> v0.1.22
    Updating tracing-subscriber v0.2.13 -> v0.2.15
    Updating unicode-segmentation v1.6.0 -> v1.7.1
    Updating uuid v0.8.1 -> v0.8.2
    Updating wasi v0.10.0+wasi-snapshot-preview1 -> v0.10.1+wasi-snapshot-preview1
    Updating wasm-bindgen v0.2.68 -> v0.2.69
    Updating wasm-bindgen-backend v0.2.68 -> v0.2.69
    Updating wasm-bindgen-futures v0.4.18 -> v0.4.19
    Updating wasm-bindgen-macro v0.2.68 -> v0.2.69
    Updating wasm-bindgen-macro-support v0.2.68 -> v0.2.69
    Updating wasm-bindgen-shared v0.2.68 -> v0.2.69
    Updating web-sys v0.3.45 -> v0.3.46
    Updating yew v0.17.3 -> v0.17.4
    Updating zeroize v1.1.1 -> v1.2.0

kellpossible · 2021-01-11T17:52:35Z

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 Amanieu/parking_lot#265

MatthewHerbst · 2022-01-13T22:59:06Z

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)

trevyn · 2022-01-14T01:39:09Z

@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.

Summary: ~~~Added new parking-lot version named parking_lot_0_12~~~ allow-large-files previous versions of parking-lot are incompatible with wasm compilation targets rustwasm/wasm-bindgen#2160 Amanieu/parking_lot#302 Reviewed By: dtolnay Differential Revision: D33985872 fbshipit-source-id: ce571ef50289fe97ff89dbf72d2c7f39fbd47758

See rustwasm/wasm-bindgen#2160

The symptom of the missing symbols is the same as discussed here: rustwasm/wasm-bindgen#2160 however, to simply identify which symbols are missing, it suffices to use wasm2wat to inspect the generated wasm, for example: wasm2wat webroot/web.wasm | grep env | less

extrawurst · 2023-11-27T12:45:31Z

My understanding is that this is basically the wasm-bindgen version of “undefined symbol when linking”.

@trevyn I cannot thank you enough for that hint. stumbled over this too just recently.
this needs much better diagnostic @alexcrichton

Liamolucko · 2023-11-27T22:26:22Z

Oh, I should probably mention that I made a tool a few months ago for debugging which crate is causing the issue: #3500 (comment)

rodrigorc added the bug label May 26, 2020

rodrigorc mentioned this issue May 29, 2020

Wasm with lto and use of f32::sin() gets an unknown reference to env module rust-lang/rust#72758

Closed

rodrigorc closed this as completed May 29, 2020

travbid added a commit to travbid/vita that referenced this issue Jun 21, 2020

ci: Downgrade Rust to avoid compiler bug causing error: Can't resolve…

cc9095f

… 'env' rustwasm/wasm-bindgen#2160 rust-lang/rust#72758

str4d mentioned this issue Mar 14, 2021

env dependency not provided rustwasm/wasm-pack#743

Open

PopcornPaws mentioned this issue May 25, 2021

I26 wasm add async zgendao/ethane#38

Merged

johansmitsnl mentioned this issue May 27, 2021

Using wasm target gives error: Error resolving module specifier “env”. Relative module specifiers must start with “./”, “../” or “/”. kellpossible/cargo-i18n#70

Closed

fredfortier mentioned this issue Jun 17, 2021

Wasm - Cannot find module env paritytech/libsecp256k1#72

Closed

mmsinclair added a commit to mmsinclair/wasm-timer that referenced this issue Oct 6, 2022

Upgrade parking_lot

5ee685e

See rustwasm/wasm-bindgen#2160

mwu-tow mentioned this issue Apr 11, 2023

Random build failure: ✘ [ERROR] Could not resolve "env" enso-org/enso#6091

Closed

Wumpf mentioned this issue May 25, 2023

Trying out https://github.com/gfx-rs/wgpu/pull/3780 directly rerun-io/rerun#2206

Closed

1 task

vizigr0u mentioned this issue Apr 3, 2024

Dependency to "env" makes triangle example not run with wasm_bindgen in browser gfx-rs/wgpu#5480

Open

jquesada2016 mentioned this issue Nov 11, 2024

Bug: using engine any in WASM generates broken imports surrealdb/surrealdb#5095

Open

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error "cannot import from modules (`env`)" in complex code. #2160

Error "cannot import from modules (`env`)" in complex code. #2160

rodrigorc commented May 26, 2020

alexcrichton commented May 26, 2020

rodrigorc commented May 26, 2020

rodrigorc commented May 26, 2020

alexcrichton commented May 26, 2020

rodrigorc commented May 28, 2020

alexcrichton commented May 28, 2020

rodrigorc commented May 28, 2020

alexcrichton commented May 29, 2020

rodrigorc commented May 29, 2020

kellpossible commented Jan 11, 2021 •

edited

Loading

kellpossible commented Jan 11, 2021

kellpossible commented Jan 11, 2021 •

edited

Loading

MatthewHerbst commented Jan 13, 2022

trevyn commented Jan 14, 2022

extrawurst commented Nov 27, 2023

Liamolucko commented Nov 27, 2023

Error "cannot import from modules (env)" in complex code. #2160

Error "cannot import from modules (env)" in complex code. #2160

Comments

rodrigorc commented May 26, 2020

Describe the Bug and Steps to Reproduce

Expected Behavior

What causes the env reference.

Versions used:

alexcrichton commented May 26, 2020

rodrigorc commented May 26, 2020

rodrigorc commented May 26, 2020

alexcrichton commented May 26, 2020

rodrigorc commented May 28, 2020

alexcrichton commented May 28, 2020

rodrigorc commented May 28, 2020

Cargo.toml

src/lib.rs

alexcrichton commented May 29, 2020

rodrigorc commented May 29, 2020

kellpossible commented Jan 11, 2021 • edited Loading

kellpossible commented Jan 11, 2021

kellpossible commented Jan 11, 2021 • edited Loading

MatthewHerbst commented Jan 13, 2022

trevyn commented Jan 14, 2022

extrawurst commented Nov 27, 2023

Liamolucko commented Nov 27, 2023

Error "cannot import from modules (`env`)" in complex code. #2160

Error "cannot import from modules (`env`)" in complex code. #2160

What causes the `env` reference.

`Cargo.toml`

`src/lib.rs`

kellpossible commented Jan 11, 2021 •

edited

Loading

kellpossible commented Jan 11, 2021 •

edited

Loading