Stream: git-wasmtime

Topic: wasmtime / PR #12520 fix: skip importing `memfd` and `rus...


view this post on Zulip Wasmtime GitHub notifications bot (Feb 04 2026 at 17:06):

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:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please 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 memfd and rustix crates if we have disabled the std feature.
This PR just excludes these packages on fiber and wasmtime if std feature is disabled.

If we don't do this, libstd.rmeta will be forcibly linked when building a package that links wasmtime in a #![no_std] environment.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 04 2026 at 17:06):

HoKim98 requested dicej for a review on PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 04 2026 at 17:06):

HoKim98 requested wasmtime-core-reviewers for a review on PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 04 2026 at 17:07):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 04 2026 at 17:08):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 04 2026 at 18:47):

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?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 04 2026 at 19:53):

github-actions[bot] added the label wasmtime:api on PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 06:32):

HoKim98 commented on PR #12520:

I think one easy way to find the std dependency is to create a new package in a separate workspace and link wasmtime against 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 error

Expected Outputs

$ ldd target/debug/libfoo.so
        statically linked

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 06:34):

HoKim98 edited a comment on PR #12520:

I think one easy way to find the std dependency is to create a new package in a separate workspace and link wasmtime against 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 error

Expected Outputs

$ cargo build -p foo
$ ldd target/debug/libfoo.so
        statically linked

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 06:35):

HoKim98 edited a comment on PR #12520:

I think one easy way to find the std dependency is to create a new package in a separate workspace and link wasmtime against 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 error

Expected Outputs

$ cargo build -p foo
$ ldd target/debug/libfoo.so
        statically linked

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 06:35):

HoKim98 edited a comment on PR #12520:

I think one easy way to find the std dependency is to create a new package in a separate workspace and link wasmtime against 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 error

Expected Outputs

$ cargo build -p foo
$ ldd target/debug/libfoo.so
        statically linked

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 17:59):

HoKim98 edited a comment on PR #12520:

I think one easy way to find the std dependency is to create a new package in a separate workspace and link wasmtime against 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 error

Expected Outputs

$ cargo build -p foo
$ ldd target/debug/libfoo.so
        statically linked

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:04):

HoKim98 requested fitzgen for a review on PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:04):

HoKim98 requested wasmtime-compiler-reviewers for a review on PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:04):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:04):

HoKim98 requested wasmtime-default-reviewers for a review on PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:04):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:07):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:09):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:14):

HoKim98 commented on PR #12520:

I've added a simple no_std validation 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_std related issues, such as #1158. In fact, it has already identified a case in cranelift-frontend where the std package was being used in a no_std environment.

Additionally, it detected a std dependency in cranelift-codegen caused by the use of std::sync::OnceCell. I believe this can be resolved using a pattern similar to Wasmtime’s sync_nostd.mod.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:15):

HoKim98 edited a comment on PR #12520:

I've added a simple no_std validation 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_std related issues, such as #1158. In fact, it has already identified a case in cranelift-frontend where the std package was being used in a no_std environment.

Additionally, it detected a std dependency in cranelift-codegen caused by the use of std::sync::OnceCell. I believe this can be resolved using a pattern similar to Wasmtime’s sync_nostd.rs.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:18):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:20):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 19:22):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 20:53):

github-actions[bot] added the label cranelift on PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

alexcrichton created PR review comment:

Could this be moved to crates/misc/test-nostd?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

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

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

alexcrichton created PR review comment:

Mind adding publish = false here too?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

alexcrichton created PR review comment:

For this I think you can probably skip the ldd part since compilation will fail if std is included due to the second global allocator

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

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

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

alexcrichton created PR review comment:

This is only tested with with one set of features, so I think these can be omitted?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 05 2026 at 23:02):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:22):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:23):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:23):

HoKim98 created PR review comment:

Sure, I will separate it into a separate PR.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:25):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:25):

HoKim98 created PR review comment:

How about crates/misc/nostd-tests? Because there is a case called crates/misc/component-async-tests, I think it would be good to match the naming sense.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:25):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:25):

HoKim98 created PR review comment:

I confirmed it.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:27):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:27):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:27):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:27):

HoKim98 created PR review comment:

I confirmed it.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:27):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:28):

HoKim98 created PR review comment:

I confirmed it.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:28):

HoKim98 created PR review comment:

I confirmed it.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:28):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:28):

HoKim98 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 01:28):

HoKim98 created PR review comment:

I confirmed it.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 17:29):

alexcrichton submitted PR review:

Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 17:33):

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 wasmtime are union'd. That means that despite this crate not asking for the std feature, for example, it's still enabled and then when the std feature 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.lock though and would be a pain to update both this second Cargo.lock and the main one. The second easiest thing to do would be to pass --exclude to various command lines (e.g. in ./ci/run-tests.py and in the CI config for running clippy). That's also a bit unfortunate though since it now requires passing --exclude locally 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

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 17:49):

HoKim98 commented on PR #12520:

How about doing the first method but ignoring Cargo.lock?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 19:22):

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.lock here. It's in theory possible to start with the workspace's Cargo.lock and 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.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 20:45):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 20:46):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 20:48):

HoKim98 updated PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 20:56):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 20:56):

alexcrichton has enabled auto merge for PR #12520.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 21:02):

alexcrichton added PR #12520 fix: skip importing memfd and rustix if std feature is disabled to the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2026 at 21:27):

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