Repository navigation
Update WASI targets to wasi-sdk-34 - #161773
Merged
Merged
Conversation
Keeping up-to-date with wasi-sdk development.
rustbot
added
A-CI
Collaborator
|
r? @marcoieni rustbot has assigned @marcoieni. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Member
|
@bors try jobs=various |
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 25, 2026
Update WASI targets to wasi-sdk-34 try-job: *various*
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
💔 Test for aae7ffe failed: CI. Failed job:
|
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
Member
Author
|
@bors try jobs=test-various |
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 25, 2026
Update WASI targets to wasi-sdk-34 try-job: test-various
Contributor
Member
|
@bors r+ rollup=always |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 26, 2026
…uwer Rollup of 7 pull requests Successful merges: - #161433 (Overhaul `rustc_middle::query`) - #158370 (rewrite never type documentation) - #160354 (update `ambiguous_glob_imported_trait` lint explanation and example.) - #161447 (Construct paramenvs from an iterator) - #161707 (pattern_type: make print format match the current syntax) - #161773 (Update WASI targets to wasi-sdk-34) - #161807 (bootstrap: skip StdarchVerify when remote testing is enabled)
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 26, 2026
Rollup merge of #161773 - alexcrichton:update-wasi-sdk, r=marcoieni Update WASI targets to wasi-sdk-34 Keeping up-to-date with wasi-sdk development.
pull Bot
pushed a commit
to xtqqczze/rust-lang-miri
that referenced
this pull request
Aug 27, 2026
…uwer Rollup of 7 pull requests Successful merges: - rust-lang/rust#161433 (Overhaul `rustc_middle::query`) - rust-lang/rust#158370 (rewrite never type documentation) - rust-lang/rust#160354 (update `ambiguous_glob_imported_trait` lint explanation and example.) - rust-lang/rust#161447 (Construct paramenvs from an iterator) - rust-lang/rust#161707 (pattern_type: make print format match the current syntax) - rust-lang/rust#161773 (Update WASI targets to wasi-sdk-34) - rust-lang/rust#161807 (bootstrap: skip StdarchVerify when remote testing is enabled)
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Aug 28, 2026
…uwer Rollup of 7 pull requests Successful merges: - rust-lang/rust#161433 (Overhaul `rustc_middle::query`) - rust-lang/rust#158370 (rewrite never type documentation) - rust-lang/rust#160354 (update `ambiguous_glob_imported_trait` lint explanation and example.) - rust-lang/rust#161447 (Construct paramenvs from an iterator) - rust-lang/rust#161707 (pattern_type: make print format match the current syntax) - rust-lang/rust#161773 (Update WASI targets to wasi-sdk-34) - rust-lang/rust#161807 (bootstrap: skip StdarchVerify when remote testing is enabled)
Brooooooklyn
added a commit
to napi-rs/napi-rs
that referenced
this pull request
Sep 9, 2026
Review follow-up on #3492. Keying the archive choice off `WASI_SDK_PATH` alone was incomplete. Without it, cargo links through `rust-lld` against the wasi-libc bundled with the Rust standard library, and Rust picked up wasi-sdk 34 in rust-lang/rust#161773, landing in 1.100. Such a toolchain needs the new archives even though no wasi-sdk is configured; the old rule would have selected the legacy 4-argument set and reproduced the very mismatch this branch fixes. Probe whichever wasi-libc actually gets linked. `wasiLibcHasNewFutexAbi()` looks for the `futex.c.obj` archive member: wasi-libc moved the futex helpers into `futex.c` in the same change that dropped `int op` (WebAssembly/wasi-libc#846), while `__wait.c` survives for other symbols, so the presence of `futex.c` — not the absence of `__wait.c` — separates the two ABIs. Verified against wasi-sdk 33 and 34 sysroots and against Rust's own bundled copies. The Rust sysroot is resolved lazily, so a configured wasi-sdk never pays for a `rustc` invocation, and an undetectable sysroot still degrades to the legacy archives. Measured on real toolchains: toolchain bundled no WASI_SDK_PATH sdk 33 sdk 34 stable 1.98 legacy legacy legacy sdk-34 nightly 09-08 new sdk-34 legacy sdk-34 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so
Brooooooklyn
added a commit
to napi-rs/napi-rs
that referenced
this pull request
Sep 9, 2026
Review follow-up on #3492. Keying the archive choice off `WASI_SDK_PATH` alone was incomplete. Without it, cargo links through `rust-lld` against the wasi-libc bundled with the Rust standard library, and Rust picked up wasi-sdk 34 in rust-lang/rust#161773, landing in 1.100. Such a toolchain needs the new archives even though no wasi-sdk is configured; the old rule would have selected the legacy 4-argument set and reproduced the very mismatch this branch fixes. Probe whichever wasi-libc actually gets linked. `wasiLibcHasNewFutexAbi()` looks for the `futex.c.obj` archive member: wasi-libc moved the futex helpers into `futex.c` in the same change that dropped `int op` (WebAssembly/wasi-libc#846), while `__wait.c` survives for other symbols, so the presence of `futex.c` — not the absence of `__wait.c` — separates the two ABIs. Verified against wasi-sdk 33 and 34 sysroots and against Rust's own bundled copies. The Rust sysroot is resolved lazily, so a configured wasi-sdk never pays for a `rustc` invocation, and an undetectable sysroot still degrades to the legacy archives. Measured on real toolchains: toolchain bundled no WASI_SDK_PATH sdk 33 sdk 34 stable 1.98 legacy legacy legacy sdk-34 nightly 09-08 new sdk-34 legacy sdk-34 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so
Brooooooklyn
added a commit
to napi-rs/napi-rs
that referenced
this pull request
Sep 9, 2026
…Rust nightly (#3492) * fix(cli): pick the emnapi archives by wasi-sdk version wasi-libc dropped the unused `int op` parameter from `__wasilibc_futex_wait_atomic_wait` and `__wasilibc_futex_wait_maybe_busy` (WebAssembly/wasi-libc#846), and wasi-sdk 34 is the first release shipping the 3-argument signature. Linking the legacy 4-argument archives against a wasi-sdk >= 34 sysroot makes wasm-ld report `function signature mismatch` and emit an invalid wasm module: wasm-ld: function signature mismatch: __wasilibc_futex_wait_atomic_wait >>> defined as (i32, i32, i32, i64) -> i32 in emnapi/lib/wasm32-wasip1-threads/libemnapi-napi-rs-mt.a(wasi_wait.c.obj) >>> defined as (i32, i32, i64) -> i32 in wasi-sdk-34.0/.../libc.a(futex.c.obj) emnapi already publishes a second archive set for the new ABI at `emnapi/lib/wasm32-wasip1-threads-wasi-sdk-34`, but `setWasiEnv()` derived the directory from the target triple alone and never picked it. Add `wasiSdkMajorVersion()`, which reads `<root>/VERSION` and falls back to `wasi/version.h`, and `selectEmnapiLinkDir()`, which uses the sdk-34 archives only when the target has threads, `WASI_SDK_PATH` resolves to a wasi-sdk >= 34, and that directory exists. The legacy directory stays the default: without `WASI_SDK_PATH`, cargo links through `rust-lld` against the wasi-libc bundled with the Rust standard library, which still uses the 4-argument signature. Also add a `wasi-sdk` CI job that links `@examples/napi` through a real wasi-sdk, on both a pre-34 and a post-34 release, so the selection cannot regress silently. The wasi-sdk 34 lane links only. Running the module needs a Rust toolchain whose `crt1` was built with wasi-sdk >= 34, which is a separate incompatibility tracked in #3491. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so * fix(cli): gate the wasi-sdk job and clarify the missing-archive error Review follow-ups on #3492. - `done` is the aggregate check that blocks merges, but its `needs` list omitted the new `wasi-sdk` job, so an archive-selection regression would not have failed the required gate. Add it. - The missing-archive error had a misleading branch: after falling back to the legacy directory, it named that directory as the missing one while telling the reader to install the wasi-sdk 34 archives. Split it into three cases and reuse the `fellBackToLegacy` condition the warning below already needs, so the two cannot drift apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so * fix(cli): detect the futex ABI from Rust's bundled wasi-libc too Review follow-up on #3492. Keying the archive choice off `WASI_SDK_PATH` alone was incomplete. Without it, cargo links through `rust-lld` against the wasi-libc bundled with the Rust standard library, and Rust picked up wasi-sdk 34 in rust-lang/rust#161773, landing in 1.100. Such a toolchain needs the new archives even though no wasi-sdk is configured; the old rule would have selected the legacy 4-argument set and reproduced the very mismatch this branch fixes. Probe whichever wasi-libc actually gets linked. `wasiLibcHasNewFutexAbi()` looks for the `futex.c.obj` archive member: wasi-libc moved the futex helpers into `futex.c` in the same change that dropped `int op` (WebAssembly/wasi-libc#846), while `__wait.c` survives for other symbols, so the presence of `futex.c` — not the absence of `__wait.c` — separates the two ABIs. Verified against wasi-sdk 33 and 34 sysroots and against Rust's own bundled copies. The Rust sysroot is resolved lazily, so a configured wasi-sdk never pays for a `rustc` invocation, and an undetectable sysroot still degrades to the legacy archives. Measured on real toolchains: toolchain bundled no WASI_SDK_PATH sdk 33 sdk 34 stable 1.98 legacy legacy legacy sdk-34 nightly 09-08 new sdk-34 legacy sdk-34 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so * perf(cli): skip the wasi-libc probe for threadless targets `needsWasiSdk34` is already gated on `hasThreads`, but the ABI probe ran before that test, so a threadless wasi build spawned `rustc --print sysroot` and read a 3 MB archive to produce a value it then discarded. emnapi ships no wasi-sdk 34 archive set for the threadless target, so the answer cannot change the outcome. Move the `hasThreads` test in front of the probe. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so * fix(build): skip crt1-reactor.o when rustc already links it rust-lang/rust#161421 added `crt1-reactor.o` to the pre-link crt objects for the dylib output kinds on WASI, landing in Rust 1.100. It was omitted before that, which is why this crate passes the object by hand to obtain the conventional `_initialize`. On a toolchain that now links it, passing it again makes the link fail: wasm-ld: error: duplicate symbol: _initialize Probe rather than compare versions: link a trivial cdylib for the target and read its export section. One short rustc invocation, measured at ~50ms, and exact on every channel — a version gate would misread the nightlies between 1.100.0-nightly opening and the change landing. Searching the module bytes for the name does not work: `_initialize` also occurs inside the linked standard library, so it matches whether or not the startup object was linked. Only the export section answers the question, hence the small section walker. When the probe cannot run the old behaviour is kept, so a toolchain that still needs the object never loses it. Verified on examples/napi, wasm32-wasip1-threads: stable 1.98, no WASI_SDK_PATH build ok, _initialize exported nightly 09-08, WASI_SDK_PATH=33 build ok, _initialize exported nightly 09-08, same, fix reverted -> wasm-ld: duplicate symbol: _initialize The nightly runs pin wasi-sdk 33 so the futex ABI stays consistent and only the startup object is exercised; the emnapi archive selection for wasi-sdk 34 is a separate change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so * test(ci): run the wasi-sdk 34 artifact on nightly The lane was link-only because the module could not instantiate: wasi-sdk 34 deleted `__wasi_init_tp`, and Rust's pre-34 `crt1-reactor.o` still calls it. Nightly ships an sdk-34 era `crt1` and links it itself, so the object that carried the undefined symbol is no longer in the module at all. Measured on `1.100.0-nightly (4aa1fbcf4 2026-09-08)` with wasi-sdk 34.0: the example suite runs 268 passed / 10 skipped through the WASI binding, and `wasm-objdump -j Import` shows no `__wasi_init_tp`. This also gives `rustc_links_reactor_crt()` its only CI coverage. Stable rustc does not link the startup object, so the sdk-33 lane never reaches that branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so * fix(cli): probe the Rust sysroot from the build cwd `rustc` is a rustup shim: it resolves `rust-toolchain.toml` and directory overrides from its working directory. `Builder.exec()` spawns Cargo with `cwd: this.options.cwd`, but the futex ABI probe ran `rustc` from the caller's directory. With `napi build --cwd <project>` the two can disagree. Measured, one caller directory, two toolchains: cwd=<caller> rustBundledWasiLibc() -> stable/.../libc.a newFutexAbi=false cwd=<project> rustBundledWasiLibc() -> nightly/.../libc.a newFutexAbi=true The probe would answer "legacy" while Cargo links nightly's wasi-libc, which selects the wrong emnapi archives and produces the signature mismatch this code exists to prevent. Pass the build cwd, and honour `RUSTC` / `CARGO_BUILD_RUSTC`, which bypass the shim; Cargo gives `RUSTC` precedence, so do the same. `execFileSync` replaces `execSync` because an overridden path can contain spaces. `build.rustc` from the project's `.cargo/config.toml` stays out of reach without invoking cargo itself. `selectEmnapiLinkDir()` takes its last two inputs as an options bag, so the test injection point and the new cwd do not become positional arguments. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so * fix(build): honour link-self-contained in the reactor probe `-C link-self-contained=no` tells rustc to leave out its own crt objects. The probe ran without the user's rustflags, so it saw `_initialize`, reported that rustc supplies the startup object, and made napi-build skip ours. The real link then had neither, and the module shipped without the export. It links cleanly, so nothing reports the loss. Reproduced end to end on nightly, with `WASI_SDK_PATH` set so the missing `-lc` resolves through the link search path napi-build already emits: CARGO_ENCODED_RUSTFLAGS = "-C\u{1f}link-self-contained=no" probe -> Some(true) -> skip manual crt exports: memory, wasi_thread_start <- no _initialize The same crate on the old always-link path exports `_initialize`, so this is a regression the probe introduced, not a pre-existing hole. Forward only `-C link-self-contained`. Passing the whole rustflags breaks the probe on anything that does not apply to an empty crate: a lone `-C link-arg=--export=napi_register_wasm_v1` makes it fail to link, which returns `None` and brings back `duplicate symbol: _initialize`. Cargo hands build scripts `CARGO_ENCODED_RUSTFLAGS`, never `RUSTFLAGS`, and separates arguments with a unit separator. Both spellings Cargo can emit are handled: `-C` plus value, and one glued `-C<value>`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LzmUqCAaDMut4aQGUhj4so --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
rust-bors Bot
pushed a commit
that referenced
this pull request
Oct 6, 2026
…arfonthey Adjust the adjustment to wasi TLS to no longer adjust Fixes #163748 Effectively reverts #160868 to unrevert the changes to wasi from #159733. As explained in #160868, now that we use wasi-sdk-34 (since #161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Oct 6, 2026
…crichton,clarfonthey Adjust the adjustment to wasi TLS to no longer adjust Fixes rust-lang#163748 Effectively reverts rust-lang#160868 to unrevert the changes to wasi from rust-lang#159733. As explained in rust-lang#160868, now that we use wasi-sdk-34 (since rust-lang#161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Oct 6, 2026
…crichton,clarfonthey Adjust the adjustment to wasi TLS to no longer adjust Fixes rust-lang#163748 Effectively reverts rust-lang#160868 to unrevert the changes to wasi from rust-lang#159733. As explained in rust-lang#160868, now that we use wasi-sdk-34 (since rust-lang#161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 6, 2026
…crichton,clarfonthey Adjust the adjustment to wasi TLS to no longer adjust Fixes rust-lang#163748 Effectively reverts rust-lang#160868 to unrevert the changes to wasi from rust-lang#159733. As explained in rust-lang#160868, now that we use wasi-sdk-34 (since rust-lang#161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 7, 2026
…crichton Switch TLS implementation for wasi and bump SDK version to 34 Fixes rust-lang#163748 Effectively reverts rust-lang#160868 to unrevert the changes to wasi from rust-lang#159733. As explained in rust-lang#160868, now that we use wasi-sdk-34 (since rust-lang#161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 7, 2026
…crichton Switch TLS implementation for wasi and bump SDK version to 34 Fixes rust-lang#163748 Effectively reverts rust-lang#160868 to unrevert the changes to wasi from rust-lang#159733. As explained in rust-lang#160868, now that we use wasi-sdk-34 (since rust-lang#161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 7, 2026
…crichton Switch TLS implementation for wasi and bump SDK version to 34 Fixes rust-lang#163748 Effectively reverts rust-lang#160868 to unrevert the changes to wasi from rust-lang#159733. As explained in rust-lang#160868, now that we use wasi-sdk-34 (since rust-lang#161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
rust-bors Bot
pushed a commit
that referenced
this pull request
Oct 8, 2026
Rollup merge of #163809 - maxdexh:destroy-the-locals, r=alexcrichton Switch TLS implementation for wasi and bump SDK version to 34 Fixes #163748 Effectively reverts #160868 to unrevert the changes to wasi from #159733. As explained in #160868, now that we use wasi-sdk-34 (since #161773), the bug in wasi-libc that motivated the workaround should no longer be an issue. To reflect the fact that we're now relying on version 34, I've also adjusted the minimum SDK version mentioned in the target docs. Note: This could probably be backported to beta, but as this is only a tier 2 target, and 1.99 is already affected by the issue, I don't think this is necessary. cc @alexcrichton r? @clarfonthey
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Keeping up-to-date with wasi-sdk development.