HoKim98 opened PR #12520 from ulagbulag:fix/skip-importing-rustix-if-std-feature-is-disabled to bytecodealliance:main:
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->We do not need to import
memfdandrustixcrates if we have disabled thestdfeature.
This PR just excludes these packages onfiberandwasmtimeifstdfeature is disabled.If we don't do this,
libstd.rmetawill be forcibly linked when building a package that links wasmtime in a#![no_std]environment.
HoKim98 requested dicej for a review on PR #12520.
HoKim98 requested wasmtime-core-reviewers for a review on PR #12520.
HoKim98 updated PR #12520.
HoKim98 updated PR #12520.
alexcrichton commented on PR #12520:
Thanks! Do you know if this is something we can check in CI? For example are there
cfg(unix)targets in Rust where the standard library is not available?
github-actions[bot] added the label wasmtime:api on PR #12520.
HoKim98 commented on PR #12520:
I think one easy way to find the
stddependency is to create a new package in a separate workspace and linkwasmtimeagainst it.Suggested CI-Only Package
# Cargo.toml [package] name = "foo" version = "0.1.0" edition = "2024" rust-version = "1.94" # rustc 1.94.0-nightly (fcd630976 2026-01-01) [profile.dev] panic = "abort" [dependencies] dlmalloc = { version = "0.2", default-features = false, features = ["global"] } wasmtime = { version = "41.0", default-features = false, features = [ "runtime", ] }// src/main.rs #![no_std] #[global_allocator] static GLOBAL: ::dlmalloc::GlobalDlmalloc = ::dlmalloc::GlobalDlmalloc; extern crate dlmalloc; extern crate wasmtime; #[panic_handler] fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { loop {} }Current Outputs
error[E0152]: found duplicate lang item `panic_impl` --> src/lib.rs:10:1 | 10 | / fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { 11 | | loop {} 12 | | } | |_^ | = note: the lang item is first defined in crate `std` (which `bitflags` depends on) = note: first definition in `std` loaded from /opt/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ad248a6e6fe48fd9.rlib = note: second definition in the local crate (`foo`) For more information about this error, try `rustc --explain E0152`. error: could not compile `foo` (lib) due to 1 previous errorExpected Outputs
$ ldd target/debug/libfoo.so statically linked
HoKim98 edited a comment on PR #12520:
I think one easy way to find the
stddependency is to create a new package in a separate workspace and linkwasmtimeagainst it.Suggested CI-Only Package
# Cargo.toml [package] name = "foo" version = "0.1.0" edition = "2024" rust-version = "1.94" # rustc 1.94.0-nightly (fcd630976 2026-01-01) [profile.dev] panic = "abort" [dependencies] dlmalloc = { version = "0.2", default-features = false, features = ["global"] } wasmtime = { version = "41.0", default-features = false, features = [ "runtime", ] }// src/main.rs #![no_std] #[global_allocator] static GLOBAL: ::dlmalloc::GlobalDlmalloc = ::dlmalloc::GlobalDlmalloc; extern crate dlmalloc; extern crate wasmtime; #[panic_handler] fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { loop {} }Current Outputs
error[E0152]: found duplicate lang item `panic_impl` --> src/lib.rs:10:1 | 10 | / fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { 11 | | loop {} 12 | | } | |_^ | = note: the lang item is first defined in crate `std` (which `bitflags` depends on) = note: first definition in `std` loaded from /opt/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ad248a6e6fe48fd9.rlib = note: second definition in the local crate (`foo`) For more information about this error, try `rustc --explain E0152`. error: could not compile `foo` (lib) due to 1 previous errorExpected Outputs
$ cargo build -p foo $ ldd target/debug/libfoo.so statically linked
HoKim98 edited a comment on PR #12520:
I think one easy way to find the
stddependency is to create a new package in a separate workspace and linkwasmtimeagainst it.Suggested CI-Only Package
# Cargo.toml [package] name = "foo" version = "0.1.0" edition = "2024" rust-version = "1.94" # rustc 1.94.0-nightly (fcd630976 2026-01-01) [profile.dev] panic = "abort" [dependencies] dlmalloc = { version = "0.2", default-features = false, features = ["global"] } wasmtime = { version = "41.0", default-features = false, features = [ "runtime", ] }// src/main.rs #![no_std] extern crate dlmalloc; extern crate wasmtime; #[global_allocator] static GLOBAL: ::dlmalloc::GlobalDlmalloc = ::dlmalloc::GlobalDlmalloc; #[panic_handler] fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { loop {} }Current Outputs
error[E0152]: found duplicate lang item `panic_impl` --> src/lib.rs:10:1 | 10 | / fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { 11 | | loop {} 12 | | } | |_^ | = note: the lang item is first defined in crate `std` (which `bitflags` depends on) = note: first definition in `std` loaded from /opt/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ad248a6e6fe48fd9.rlib = note: second definition in the local crate (`foo`) For more information about this error, try `rustc --explain E0152`. error: could not compile `foo` (lib) due to 1 previous errorExpected Outputs
$ cargo build -p foo $ ldd target/debug/libfoo.so statically linked
HoKim98 edited a comment on PR #12520:
I think one easy way to find the
stddependency is to create a new package in a separate workspace and linkwasmtimeagainst it.Suggested CI-Only Package
# Cargo.toml [package] name = "foo" version = "0.1.0" edition = "2024" rust-version = "1.94" # rustc 1.94.0-nightly (fcd630976 2026-01-01) [profile.dev] panic = "abort" [dependencies] dlmalloc = { version = "0.2", default-features = false, features = ["global"] } wasmtime = { version = "41.0", default-features = false, features = [ "runtime", ] }// src/lib.rs #![no_std] extern crate dlmalloc; extern crate wasmtime; #[global_allocator] static GLOBAL: ::dlmalloc::GlobalDlmalloc = ::dlmalloc::GlobalDlmalloc; #[panic_handler] fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { loop {} }Current Outputs
error[E0152]: found duplicate lang item `panic_impl` --> src/lib.rs:10:1 | 10 | / fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { 11 | | loop {} 12 | | } | |_^ | = note: the lang item is first defined in crate `std` (which `bitflags` depends on) = note: first definition in `std` loaded from /opt/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ad248a6e6fe48fd9.rlib = note: second definition in the local crate (`foo`) For more information about this error, try `rustc --explain E0152`. error: could not compile `foo` (lib) due to 1 previous errorExpected Outputs
$ cargo build -p foo $ ldd target/debug/libfoo.so statically linked
HoKim98 edited a comment on PR #12520:
I think one easy way to find the
stddependency is to create a new package in a separate workspace and linkwasmtimeagainst it.Suggested CI-Only Package
# Cargo.toml [package] name = "foo" version = "0.1.0" edition = "2024" rust-version = "1.94" # rustc 1.94.0-nightly (fcd630976 2026-01-01) [lib] crate-type = ["cdylib"] [profile.dev] panic = "abort" [dependencies] dlmalloc = { version = "0.2", default-features = false, features = ["global"] } wasmtime = { version = "41.0", default-features = false, features = [ "runtime", ] }// src/lib.rs #![no_std] extern crate dlmalloc; extern crate wasmtime; #[global_allocator] static GLOBAL: ::dlmalloc::GlobalDlmalloc = ::dlmalloc::GlobalDlmalloc; #[panic_handler] fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { loop {} }Current Outputs
error[E0152]: found duplicate lang item `panic_impl` --> src/lib.rs:10:1 | 10 | / fn panic_handler(_info: &::core::panic::PanicInfo<'_>) -> ! { 11 | | loop {} 12 | | } | |_^ | = note: the lang item is first defined in crate `std` (which `bitflags` depends on) = note: first definition in `std` loaded from /opt/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ad248a6e6fe48fd9.rlib = note: second definition in the local crate (`foo`) For more information about this error, try `rustc --explain E0152`. error: could not compile `foo` (lib) due to 1 previous errorExpected Outputs
$ cargo build -p foo $ ldd target/debug/libfoo.so statically linked
HoKim98 requested fitzgen for a review on PR #12520.
HoKim98 requested wasmtime-compiler-reviewers for a review on PR #12520.
HoKim98 updated PR #12520.
HoKim98 requested wasmtime-default-reviewers for a review on PR #12520.
HoKim98 updated PR #12520.
HoKim98 updated PR #12520.
HoKim98 updated PR #12520.
HoKim98 commented on PR #12520:
I've added a simple
no_stdvalidation package for PoC purposes. While the package name, description, and location are currently placeholders, I can confirm the functionality is solid.This new commit will help proactively detect and prevent
no_stdrelated issues, such as #1158. In fact, it has already identified a case incranelift-frontendwhere thestdpackage was being used in ano_stdenvironment.Additionally, it detected a std dependency in
cranelift-codegencaused by the use ofstd::sync::OnceCell. I believe this can be resolved using a pattern similar to Wasmtime’ssync_nostd.mod.
HoKim98 edited a comment on PR #12520:
I've added a simple
no_stdvalidation package for PoC purposes. While the package name, description, and location are currently placeholders, I can confirm the functionality is solid.This new commit will help proactively detect and prevent
no_stdrelated issues, such as #1158. In fact, it has already identified a case incranelift-frontendwhere thestdpackage was being used in ano_stdenvironment.Additionally, it detected a
stddependency incranelift-codegencaused by the use ofstd::sync::OnceCell. I believe this can be resolved using a pattern similar to Wasmtime’ssync_nostd.rs.
HoKim98 updated PR #12520.
HoKim98 updated PR #12520.
HoKim98 updated PR #12520.
github-actions[bot] added the label cranelift on PR #12520.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Could this be moved to
crates/misc/test-nostd?
alexcrichton created PR review comment:
Could these changes to crates be split out into a separate PR? I wouldn't expect that this would be required to land but instead would be an enhancement to the nostd test in a subsequent PR
alexcrichton created PR review comment:
Mind adding
publish = falsehere too?
alexcrichton created PR review comment:
For this I think you can probably skip the
lddpart since compilation will fail ifstdis included due to the second global allocator
alexcrichton created PR review comment:
We currently only have LICENSE files for published crates, but this crate won't be published so it's fine to omit this
alexcrichton created PR review comment:
This is only tested with with one set of features, so I think these can be omitted?
alexcrichton created PR review comment:
Given that this crate is specifically testing building without
std, I think this should probabyl not need to be here.
alexcrichton created PR review comment:
FWIW it's ok to skip the LLM overview here. This is just a crate to build in CI as part of a test, and I don't think it warrants such verbose documentation.
HoKim98 updated PR #12520.
HoKim98 submitted PR review.
HoKim98 created PR review comment:
Sure, I will separate it into a separate PR.
HoKim98 submitted PR review.
HoKim98 created PR review comment:
How about
crates/misc/nostd-tests? Because there is a case calledcrates/misc/component-async-tests, I think it would be good to match the naming sense.
HoKim98 submitted PR review.
HoKim98 created PR review comment:
I confirmed it.
HoKim98 submitted PR review.
HoKim98 created PR review comment:
I initially considered it as a variable driven by feature dependency. Upon further consideration, I believe the same functionality could be achieved by activating as many features as possible from the scratch.
HoKim98 submitted PR review.
HoKim98 created PR review comment:
I confirmed it.
HoKim98 submitted PR review.
HoKim98 created PR review comment:
I confirmed it.
HoKim98 created PR review comment:
I confirmed it.
HoKim98 submitted PR review.
HoKim98 submitted PR review.
HoKim98 created PR review comment:
I confirmed it.
alexcrichton submitted PR review:
Thanks!
alexcrichton commented on PR #12520:
Hm ok seeing that CI is failing... this is unfortunately going to be a bit tricky. The problem is that this is a workspace member which means that when testing/linting/etc the entire workspace all features for
wasmtimeare union'd. That means that despite this crate not asking for thestdfeature, for example, it's still enabled and then when thestdfeature is enabled it predictably causes the test to fail to build.The easiest thing to do would probably be to exclude this as a workspace member. That would generate a separate
Cargo.lockthough and would be a pain to update both this secondCargo.lockand the main one. The second easiest thing to do would be to pass--excludeto various command lines (e.g. in./ci/run-tests.pyand in the CI config for running clippy). That's also a bit unfortunate though since it now requires passing--excludelocally as well when running the commands manually.All-in-all I might say that we should forgo the test on this one. I apologize for the runaround here but I didn't realize the effect that this would have on CI and local development. If you agree I'm happy to flag-for-merge with the test removed from this PR
HoKim98 commented on PR #12520:
How about doing the first method but ignoring
Cargo.lock?
alexcrichton commented on PR #12520:
The risk of that is that then we're not insulated against new publications of crates accidentally breaking us in CI. In general we want CI to be as reprodcible as possible across runs, which is one of the primary reason to include
Cargo.lockhere. It's in theory possible to start with the workspace'sCargo.lockand have that get automatically trimmed down, but that's where I feel the infrastructure here isn't really buying too too much and I think it's reasonable to skip the test.
HoKim98 commented on PR #12520:
I’m sorry to hear that this might not be the best news. In that case, I will personally set up a separate repository for CI to manage no_std compatibility for these changes. I’ll go ahead and roll back the commits related to the no_std CI implementation.
HoKim98 updated PR #12520.
HoKim98 updated PR #12520.
alexcrichton submitted PR review.
alexcrichton has enabled auto merge for PR #12520.
alexcrichton added PR #12520 fix: skip importing memfd and rustix if std feature is disabled to the merge queue.
github-merge-queue[bot] removed PR #12520 fix: skip importing memfd and rustix if std feature is disabled from the merge queue.
Last updated: Feb 24 2026 at 04:36 UTC