STATUS_ENTRYPOINT_NOT_FOUND error with x86_64-pc-windows-gnu on Windows Server 2019 in GitHub action #123999
Comments
rustbot
added
the
needs-triage
|
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 cc @mati865 in case you've heard of anything like this before |
Noratrieb
added
O-windows
|
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 |
|
Hm... I ran windows-2019windows-latestNote that |
|
Yeah, that is probably the culprit but mingw-w64 links If it's caused by miingw-w64 toolchain preinstalled on |
|
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 https://github.com/actions/runner-images/blob/main/images/windows/Windows2019-Readme.md, my first impression is that mingw-w64 isn't preinstalled on the |
|
Various tools like Perl might come with GCC. Could you determine location of |
|
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 https://github.com/mxschmitt/action-tmate to explore around. Alternatively, I could just run a fixed list of commands. If there's a set of EDIT: Based on your question, I might need to just run EDIT2: |
|
Here are the versions of |
|
Thanks, apparently there was a bug in mingw-w64 fixed in 2020: mirror/mingw-w64@68d0e7d |
|
Oh, weird. 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: https://github.com/actions/runner-images/blob/7993ee591358052f1dd23c6135281e24b80b572f/images/windows/scripts/build/Install-Mingw64.ps1 EDIT2: It was documented after all. I had to search for "gcc", not "mingw". |
|
I was rather confused because https://www.mingw-w64.org/downloads/ states that the latest version from the 8.x series is 8.0.2, but the version installed of I might ask in the EDIT: Filed actions/runner-images#9702. Depending on their response, if they decide not to update, it's possible |
Use raw-dylib for Windows synchronization functions Fixes rust-lang#123999 by using the raw-dylib feature to specify the DLL to load the Windows futex functions from (e.g. [`WaitOnAddress`](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress)). This avoids reliance on the import library causing that issue. With apologies to `@bjorn3,` as it's currently necessary to revert this for cranelift.
|
For some reason, my original issue description code snippet mentioned |
|
Given that #124019 seems to be in progress and would close this issue, I mentioned that in actions/runner-images#9702 for extra transparency. |
Use raw-dylib for Windows synchronization functions Fixes rust-lang#123999 by using the raw-dylib feature to specify the DLL to load the Windows futex functions from (e.g. [`WaitOnAddress`](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress)). This avoids reliance on the import library causing that issue. With apologies to `@bjorn3,` as it's currently necessary to revert this for cranelift.
Rollup merge of rust-lang#124019 - ChrisDenton:futex-raw-dylib, r=joboet Use raw-dylib for Windows synchronization functions Fixes rust-lang#123999 by using the raw-dylib feature to specify the DLL to load the Windows futex functions from (e.g. [`WaitOnAddress`](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress)). This avoids reliance on the import library causing that issue. With apologies to ``@bjorn3,`` as it's currently necessary to revert this for cranelift.
|
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). |
This CL is the application of the upstream CL listed below. It adjusts the symbols lists for Kernel32.dll to handle the removeal of several symbols that Microsoft claims are present but aren't. This is needed to fix a build breakage for the Windows Rust 1.78.0 toochain. * mirror/mingw-w64@68d0e7d * rust-lang/rust#123999 Test: ./build.sh Bug: 333887339 Change-Id: I850b89fc20faffee9ff37ade5ab460931daf3a79
The following GitHub action fails with nightly-2024-02-27 but passes with nightly-2024-02-26 for (I believe) any project with a
build.rsfile:The error I got is the following:
This only affects x86_64-pc-windows-gnu (not MVSC), and switching from
windows-2019towindows-2022fixes the issue.I have reproduced the issue in patowen/lavagna#1. I may end up deleting that repo in the future, so for posterity, I've included all the code below:
Example project to reproduce the issue:
.github\workflows\ci.yml:(See above)
src\main.rs:
build.rs:
Cargo.toml:
The original discovery of this issue is reported in alepez/lavagna#29.
Meta
Running
rustc --version --verboseyielded the following for the latest nightly version without the issue:Running
rustc --version --verboseon 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 text was updated successfully, but these errors were encountered: