Code change:
<ins> From 0d741cf82c3c908616abd39dc84ebf7d8702e0c3 Mon Sep 17 00:00:00 2001 From: Chris Denton <chris@chrisdenton.dev> Date: Tue, 16 Apr 2024 15:51:34 +0000 Subject: [PATCH] Revert use raw-dylib for Windows futex APIs --- library/std/src/sys/pal/windows/c.rs | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/library/std/src/sys/pal/windows/c.rs b/library/std/src/sys/pal/windows/c.rs index 9d58ce05f01..1c828bac4b6 100644 --- a/library/std/src/sys/pal/windows/c.rs +++ b/library/std/src/sys/pal/windows/c.rs @@ -357,19 +357,7 @@ pub fn GetTempPath2W(bufferlength: u32, buffer: PWSTR) -> u32 { } #[cfg(not(target_vendor = "win7"))] -// Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. -#[cfg_attr( -    target_arch = "x86", -    link( -        name = "api-ms-win-core-synch-l1-2-0", -        kind = "raw-dylib", -        import_name_type = "undecorated" -    ) -)] -#[cfg_attr( -    not(target_arch = "x86"), -    link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") -)] +#[link(name = "synchronization")] extern "system" { pub fn WaitOnAddress( address: *const c_void, -- 2.42.0.windows.2 </ins>

Related discussion:
text: Based on , my first impression is that mingw-w64 isn't preinstalled on the image. Unless Windows Subsystem for Linux is relevant, I assume that the mingw-w64 toolchain is installed as part of the run of .
Various tools like Perl might come with GCC. Could you determine location of and ?
I'm not sure. I've only been able to reproduce this via a GitHub action, not on my own machine, although I might be able to use something like to explore around. Alternatively, I could just run a fixed list of commands. If there's a set of commands I can run to answer any questions you have, please let me know. I'm not sure how the Rust toolchain determines which version of to run when building Rust code, but that seems like something you might know. EDIT: Based on your question, I might need to just run with the two applications you asked about. EDIT2: and are both in according to .
Here are the versions of based on running :
Thanks, apparently there was a bug in mingw-w64 fixed in 2020: IIRC this toolchain is older than that so it's indeed a bug in mingw-w64 shipped with this .
Oh, weird. also comes shipped with so this image generally has up-to-date packages. I also didn't see mingw or mingw-w64 mentioned anywhere in its README, so now I'm wondering if there's a bug in the image itself. I expect this means that no action will be needed for this particular issue unless we want to be more robust to bad environments like this. EDIT: It looks like it's defined here: EDIT2: It was documented after all. I had to search for "gcc", not "mingw".
I was rather confused because states that the latest version from the 8.x series is 8.0.2, but the version installed of in the the Windows 2019 image is 8.1.0, which seems like it shouldn't exist. However, based on the releases of , the number after the is probably what's important, which means that we're on version 6.0.0, which is indeed before the fix. I might ask in the project to see if it's worth updating mingw64 for this reason.