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