I've just used unimplemented!() and it seems those functions are not called.
Julien Cretin (ia0) has marked this topic as resolved.
I'm wondering if there's a way to avoid doing that
In theory this should bottom out with crate features for Wasmtime, where if neither custom-virtual-memory nor custom-native-signals is enabled it shouldn't require anything more thatn wasmtime_tls_*
This might be a bug in Wasmtime though where we're detecting linux for i686-unknown-linux-gnu and assuming there's virtual memory when no_std is otherwise active? Would you be able to post a reproduction and/or work-in-progress which requires the symbols that it shouldn't?
In theory this should bottom out with crate features for Wasmtime, where if neither
custom-virtual-memorynorcustom-native-signalsis enabled it shouldn't require anything more thatnwasmtime_tls_*
I'm using default-features = false and features = ["async", "runtime"].
assuming there's virtual memory when no_std is otherwise active?
Mmm... the library that depends on Wasmtime is no-std, but the final binary isn't.
Would you be able to post a reproduction
You can clone https://github.com/ia0/wasefire.git, checkout the branch tmp/pulley-i686-linux, move to the crates/runner-host directory, and run:
PKG_CONFIG_SYSROOT_DIR=/usr/lib/i386-linux-gnu/pkgconfig cargo build --release --target=i686-unknown-linux-gnu --features=debug,pulley
You can uncomment the lines commented in the last commit to fix the issue. Those are in the crates/scheduler/src/applet/store/pulley.rs file.
You might need some dependencies like libudev-dev, libssl-dev, libssl-dev:i386, gcc-multilib, and linux-tools-common (or usbip).
Thanks! I was able to confirm that https://github.com/bytecodealliance/wasmtime/pull/11568 should make this go away and work as expected
Cool, thanks a lot!
Last updated: Dec 06 2025 at 06:05 UTC