UWP target (e.g. x86_64-uwp-windows-msvc) is broken

[anter1]

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:

rust/library/std/src/sys/pal/windows/fs/remove_dir_all.rs

Line 55 in 446649d

c::NtOpenFile(&mut handle, access, object_attribute, &mut io_status, share, options);

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.

[jieyouxu]

cc @bdbai for FYI

[bdbai]

It looks like NtOpenFile needs a dummy implementation for UWP, same as NtCreateFile here

rust/library/std/src/sys/pal/windows/c.rs

Line 224 in a96fa31

pub fn NtCreateFile(

Before a patch is available to fix this, a workaround will be to turn on lto and use release build only so that the staticlib will not require this symbol, given std::fs::remove_dir_all is not used anywhere in your library.

[bdbai]

I just filed #138276 and verified locally in Visual Studio that a new UWP app was able to link against a staticlib calling std::fs::remove_dir_all.