-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update MinGW in Windows Server 2019 image for (probably) future Rust support #9702
Comments
Hello @patowen! |
Regarding whether to upgrade this, I don't have a strong stake in the final decision. The underlying issue I'm wanting to resolve can be resolved from several different angles, and this is just one of them:
I don't have a good sense of all the pros and cons of updating the mingw version or the other options, as I lack experience in GitHub actions and internal aspects of Rust, so I don't want to make any strong recommendations here. |
Speaking only for Rust...
Using the system mingw (if available) is usually preferable so I don't think this is a desirable option.
This would workaround the issue for the nightly compiler. However, this has reached beta so it would need a backport to avoid affecting the next stable release. I don't yet know if a backport would be accepted considering this is, technically speaking, a bug outside of Rust itself. But I'll ask. Note though that it is just a workaround for Rust's standard library. It obviously won't fix it for other use cases (e.g. a C++ application importing these functions). Then again, considering this is the first report, perhaps it's not a pressing issue otherwise. |
Hello @patowen. Unfortunately due maintain concerns we not ready to upgrade mingw for windows images Because that could be make cause huge impact for other users. I am closing this tread but we will continue track similar issues for possible changing decision. If you have additional questions feel free to ask. |
Thanks for the heads up, and no worries at all! Fortunately, I saw that the "beta-accepted" label has been applied to the Rust PR, so it seems like it will be backported after all. Especially given this change in the landscape, I believe I also agree with this decision to hold off on upgrading mingw. |
Tool name
MinGW64
Tool license
GNU
Add or update?
Desired version
Any version with "rt_v8" or above
Approximate size
No response
Brief description of tool
The current version of mingw installed on Windows 2019 hosts is
x86_64-8.1.0-release-posix-seh-rt_v6-rev0.7z
(or thei686
equivalent). I believert_v6
means that it corresponds to v6.0.0 from September 2018.There was a fix targeting v8.0.0 (mirror/mingw-w64@68d0e7d) released in 2020 that is necessary for the
x86_64-pc-windows-gnu
toolchain ofrustc 1.78.0-beta.7
to work properly when installed with the default configuration. With the current version, trying to build Rust programs with that toolchain results in an ambiguousSTATUS_ENTRYPOINT_NOT_FOUND
error.More details about this particular issue can be found in rust-lang/rust#123999.
I am aware that this was discussed in #9009 for a different reason, and the decision was not yet to update. I am mainly filing this issue to help with discoverability and in case this extra use-case is enough of a reason to reconsider.
URL for tool's homepage
No response
Provide a basic test case to validate the tool's functionality.
No response
Platforms where you need the tool
Runner images where you need the tool
Can this tool be installed during the build?
Tool installation time in runtime
No response
Are you willing to submit a PR?
I unfortunately don't have enough experience with mingw64 to confidently help here.
The text was updated successfully, but these errors were encountered: