Change:
The following GitHub action fails with nightly-2024-02-27 but passes with nightly-2024-02-26 for (I believe) any project with a file: The error I got is the following: This only affects x8664-pc-windows-gnu (not MVSC), and switching from to fixes the issue. I have reproduced the issue in I may end up deleting that repo in the future, so for posterity, I've included all the code below: <details<summaryExample project to reproduce the issue:workflows (See above) src </detailsThe original discovery of this issue is reported in Running yielded the following for the latest nightly version without the issue: Running on three versions with_ the issue (the next nightly version, the latest nightly version, and the current beta) yielded the following: This issue is not present in rustc 1.77.2 (the latest stable version).
The imports should mostly be shared between msvc and gnu so the fact the targets differ is a bit puzzling. My hypothesis would be that mingw on Windows Server 2019 is using an older version of an import library that maps one or more functions to the wrong DLL. Specifically I think this could be caused by the import library. cc in case you've heard of anything like this before
I doubt it's a problem with the old MinGW-w64; in that case, the program would fail to link. I helped with a similar issue recently, and it was caused by the wrong being loaded. There are two DLLs called that, and if a manifest is not provided, Windows will load the wrong one:
Hm... I ran on both windows-2019 and windows-latest and the import tables do look different (see ). <details<summarywindows-2019</summary</details<details<summarywindows-latest</summary</detailsNote that is listed under in windows-2019 but it's more correctly listed under in windows-latest.
Yeah, that is probably the culprit but mingw-w64 links from since mid 2016: If it's caused by miingw-w64 toolchain preinstalled on image it must be terribly out of date.
Quite possibly it is that out of date. The other explanation would be it's coming from somewhere else, which Is a bit worrying.
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. EDIT: Filed Depending on their response, if they decide not to update, it's possible could be fixed instead to stop trying to install Rust over an incompatible version of MinGW.
For some reason, my original issue description code snippet mentioned instead of . I think that's because I copy/pasted the wrong version, when I was seeing whether the workaround worked (which I believe it did). I apologize if that caused any confusion. I've now edited the description to fix this mistake.
Given that seems to be in progress and would close this issue, I mentioned that in for extra transparency.
Thank you for all your help on this! It's awesome that all this happened in only 4 days. I can confirm on my end that this issue is now fully resolved on the latest nightly release of Rust (2024-04-19).

Discussion:
<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>

} #[cfg(not(target_vendor = "win7"))] <del> #[link(name = "synchronization")] </del> <ins> // 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") )] </ins> extern "system" { pub fn WaitOnAddress( address: *const c_void,