ic-rusqlite 0.4.3 incompatible with Rust 1.91.0: WASM import module mismatch for `time`

[marc0olo]

Bug

ic-rusqlite 0.4.3 fails to link with Rust 1.91.0 (released 2025-10-28). Both the precompiled and compile_sqlite features are affected.

Error (with precompiled feature):

rust-lld: error: import module mismatch for symbol: time
>>> defined as env in libsqlite3.a(sqlite3.o)
>>> defined as ic0 in libic_cdk-...rlib

Error (with compile_sqlite feature): same import module mismatch.

Root cause

Rust 1.91.0's wasm-ld added strict enforcement of WASM module-qualified import consistency. SQLite calls time() from C — when compiled for wasm32-wasip1 this becomes a WASM import from module env. ic-cdk 0.18 imports time from module ic0. When both appear in the same link step, wasm-ld 1.91.0 rejects them as conflicting import module declarations for the same symbol.

Rust 1.90.0 was lenient about this mismatch and let it through. Rust 1.91.0 made it a hard error.

Versions

• ic-rusqlite: 0.4.3
• ic-cdk: 0.18.7 (via ic-rusqlite)
• target: wasm32-wasip1
• Rust 1.90.0 (2025-09-14): works
• Rust 1.91.0 (2025-10-28): broken
• Rust 1.91.0 is the current stable as of 2026-04.

Workaround (for consumers)

Pin Rust to 1.90.0 via rust-toolchain.toml:

[toolchain]
channel = "1.90.0"
targets = ["wasm32-wasip1"]

Recommended fix

ic-rusqlite needs to ensure that time is not a naked WASM import from module env in the final binary. Options:

1. Provide a time shim in Rust that SQLite's env::time import resolves to at link time, so it never appears as an unresolved WASM import.
2. Rebuild libsqlite3.a in a way that avoids the direct env::time import (e.g. link against a polyfill that resolves it before the .a is archived).
3. Add CI that builds against the latest stable Rust — this would have caught the regression when 1.91.0 shipped in October 2025.

[wasm-forge]

hello Marco, it seems that the problem only occurs in Rust 1.91, switching to the later (1.92, ..., 1.94.1) version fixes the issue.

[marc0olo]

Thanks for confirming! I dug into exactly why 1.91.0 is the only affected version — thought the full analysis might be useful here.

Root cause: a rustc codegen regression, not a wasm-ld change

The initial bug report blamed wasm-ld adding stricter enforcement in 1.91.0, but that framing is wrong. The import module mismatch hard error in lld/wasm/SymbolTable.cpp (setImportAttributes) is identical in LLVM 20 and 21 — it has always been a hard linker error. wasm-ld is not the variable.

The actual cause is a one-line rustc codegen regression introduced by PR #144678 ("Make no_mangle on foreign items explicit instead of implicit"), merged Aug 12, 2025, and shipped in 1.91.0.

Background: wasm force-mangling

For wasm32-* targets, rustc has a long-standing workaround for LLVM bug #44316: any foreign item declared inside a #[link(wasm_import_module = "...")] block gets force-mangled even though foreign items are normally unmangled. Without this, two crates importing different symbols from different wasm modules but with the same C name would collide at the linker.

ic0::time() is declared inside #[link(wasm_import_module = "ic0")], so rustc normally mangles it to something like _ZN3ic04time17h.... With a unique mangled name it never collides with SQLite's unmangled time import from module env.

What PR #144678 broke

In compute_symbol_name(), the condition deciding whether to force-mangle was accidentally changed from:

// CORRECT: looks up the foreign item's own crate
tcx.wasm_import_module_map(def_id.krate).contains_key(&def_id.into())

to:

// WRONG (1.91.0 only): always looks up the local crate
tcx.wasm_import_module_map(LOCAL_CRATE).contains_key(&def_id.into())

When ic0::time is defined in the external ic0 crate, its DefId is not in the local crate's map → lookup returns false → no force-mangling → time lands in the object file as a bare unmangled symbol with a wasm-import-module: ic0 IR attribute → wasm-ld sees two time imports with conflicting modules (ic0 vs env) → hard error.

Why the exact regression window is 1.91.0 only

Version	Status	Why
1.90.0	✅ works	PR #144678 merged Aug 12; 1.90 branched Aug 1 — missed the window
1.91.0	❌ breaks	PR #144678 in; fix not yet in
1.91.1	✅ works	One-line fix via PR #148363, backported via PR #148591
1.92.0+	✅ works	Same backport included in the 1.92 beta branch

The fix in PR #148363 is simply changing LOCAL_CRATE back to def_id.krate.

Relevant Rust issue tracking this: rust-lang/rust#148347.

---

So the workaround for consumers is: avoid 1.91.0 specifically. Any other version (including the current stable) is fine. Worth noting in the README or release notes if you haven't already!