Undefined symbols from pthread in empty staticlib for wasip1

[benozol]

Code

I tried this code:

I expected to see this happen: compiling an empty lib with crate type staticlib to target wasm32-wasi creates a relocatable Wasm .a without undefined symbols for pthreads.

Instead, this happened: the .a contains undefined symbols for pthreads (the .wasm has no undefined symbols)

repro.sh

rustc 1.93.1 (01f6ddf75 2026-02-11)
=== undefined pthread symbols ===

rustc 1.94.1 (e408947bf 2026-03-25)
=== undefined pthread symbols ===
--- std-c91e563353c7e174.std.728e8bab36f00-cgu.0.rcgu.o ---
   - 454: F <env.pthread_join> func=91 [ undefined binding=global vis=default ]
   - 1278: F <env.pthread_detach> func=142 [ undefined binding=global vis=default ]
 
rustc 1.95.0 (59807616e 2026-04-14)
=== undefined pthread symbols ===
--- std-d64733c6df5094a8.std.a88812da5ee6ad9e-cgu.0.rcgu.o ---
   - 281: F <env.pthread_attr_init> func=52 [ undefined binding=global vis=default ]
   - 282: F <env.pthread_attr_setstacksize> func=53 [ undefined binding=global vis=default ]
   - 285: F <env.pthread_attr_destroy> func=55 [ undefined binding=global vis=default ]
   - 292: F <env.pthread_create> func=56 [ undefined binding=global vis=default ]
   - 294: F <env.pthread_join> func=57 [ undefined binding=global vis=default ]
   - 819: F <env.pthread_detach> func=114 [ undefined binding=global vis=default ]
   - 
rustc 1.97.0-nightly (37d85e592 2026-04-28)
=== undefined pthread symbols ===
--- std-e31abec1fa1087a7.std.22fe8ebee811282d-cgu.0.rcgu.o ---
   - 281: F <env.pthread_attr_init> func=52 [ undefined binding=global vis=default ]
   - 282: F <env.pthread_attr_setstacksize> func=53 [ undefined binding=global vis=default ]
   - 285: F <env.pthread_attr_destroy> func=55 [ undefined binding=global vis=default ]
   - 292: F <env.pthread_create> func=56 [ undefined binding=global vis=default ]
   - 294: F <env.pthread_join> func=57 [ undefined binding=global vis=default ]
   - 826: F <env.pthread_detach> func=114 [ undefined binding=global vis=default ]

Triggered by #153634?

Version it worked on

It most recently worked on: 1.93

Version with regression

rustup run 1.94 rustc --version --verbose:

rustc 1.94.1 (e408947bf 2026-03-25)
binary: rustc
commit-hash: e408947bfd200af42db322daf0fadfe7e26d3bd1
commit-date: 2026-03-25
host: aarch64-apple-darwin
release: 1.94.1
LLVM version: 21.1.8

rustup run nightly rustc --version --verbose:

rustc 1.97.0-nightly (37d85e592 2026-04-28)
binary: rustc
commit-hash: 37d85e592f9ae5f20f7d9a9f99785246fa7298da
commit-date: 2026-04-28
host: aarch64-apple-darwin
release: 1.97.0-nightly
LLVM version: 22.1.4

[the8472]

Not sure if this is intended behavior or not (I'm not a wasm expert), so..

CC @jieyouxu and

@rustbot ping wasm

[rustbot]

Hey WASM notification group! This issue or PR could use some WebAssembly-specific
guidance. Could one of you weigh in? Thanks <3

(In case it's useful, here are some instructions for tackling these sorts of
issues).

cc @alexcrichton @burakemir @hoodmane @juntyr

[alexcrichton]

@benozol can you explain at a higher level why you're expecting this or what you're hoping to achieve? This is expected behavior because Rust *.a staticlib files still depend on libc/standard APIs. For example if you compile for a native platform and produce a staticlib it's going to have undefined symbols for functions/data found in libc.so on your native system. (or something else on Windows).

The undefined pthread_* symbols are functions that the standard library is using from libc.a, provided in wasi-sdk as a standard wasi toolchain. Rust also ships with its own libc.a, but that's not included in a Rust staticlib since it's a "self contained sysroot" onl used during linking.

[benozol]

Thanks for the explanations. At the time of the report we were using wasi-sdk 19, which did not provide these symbols, and we hit linking errors after an update of Rust to 1.95. Now we updated to wasi-sdk 25 and only pthread_detach remains undefined (haven't checked newer versions of wasi-sdk yet).

Because we got that linking error after a rust update it felt like a regression, but there is of course no need to support such an old wasi sdk. A note (or check) about the compatibility between rust version and wasi-sdk version may be helpful.

[alexcrichton]

I've submitted #156258 to document the required version. Note that this will change over time though.