Repository navigation
UWP target (e.g. x86_64-uwp-windows-msvc) is broken #138257
Description
I tried to compile x86_64-uwp-windows-msvc on nightly rust using -Z build-std . I used staticlib as target type. Then I tried to link the successfully created .lib file into my exe - outside of rust ecosystem. The linker failed with this error:
error LNK2019: unresolved external symbol __imp_NtOpenFile referenced in function _ZN3std3sys3pal7windows2fs14remove_dir_all12nt_open_file17h43bb929b19188a87E
My successful cargo command which created my staticlib which is unusable in UWP is:
cargo.exe rustc --lib --target=x86_64-uwp-windows-msvc --package pkg_name --manifest-path C:/path/to/Cargo.toml -Z build-std=std,panic_abort -- -Cdefault-linker-libraries=no
The issue is due to rust's std lib using NtOpenFile function which is not available for UWP applications. This regression was introduced in bb9d5c4
The usage of the function is not guarded by the #[cfg(target_vendor = "uwp")] feature here:
The way I understand it, all uwp targets are unusable since the above mentioned commit around September 2024 because the rust's std library uses function not allowed for uwp applications.
Activity
jieyouxu commentedon Mar 9, 2025
cc @bdbai for FYI
bdbai commentedon Mar 9, 2025
It looks like
NtOpenFileneeds a dummy implementation for UWP, same asNtCreateFilehererust/library/std/src/sys/pal/windows/c.rs
Line 224 in a96fa31
Before a patch is available to fix this, a workaround will be to turn on
ltoand usereleasebuild only so that thestaticlibwill not require this symbol, givenstd::fs::remove_dir_allis not used anywhere in your library.bdbai commentedon Mar 9, 2025
I just filed #138276 and verified locally in Visual Studio that a new UWP app was able to link against a
staticlibcallingstd::fs::remove_dir_all.Rollup merge of rust-lang#138276 - bdbai:fix-uwp-ntopenfile, r=ChrisD…
Unrolled build for rust-lang#138276
Rollup merge of rust-lang#138276 - bdbai:fix-uwp-ntopenfile, r=ChrisD…