Update MinGW in Windows Server 2019 image for (probably) future Rust support

[patowen]

Tool name

MinGW64

Tool license

GNU

Add or update?

• Add
• 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 the i686 equivalent). I believe rt_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 of rustc 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 ambiguous STATUS_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

• Azure DevOps
• GitHub Actions

Runner images where you need the tool

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Can this tool be installed during the build?

Based on https://github.com/actions/runner-images/issues/9009, it is probably possible, although the purpose of this request is to try avoiding potential pitfalls.

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.

[MaksimZhukov]

Hello @patowen!
We will consider upgrading the MinGW version and will let you know as soon as we make a decision.

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

• Upgrading mingw so that the default gcc version in the PATH points to one that works well with rustc 1.78.0-beta.7 (the suggestion in this ticket)
• Making rustc more robust in handling older versions of mingw (which might happen as part of Use raw-dylib for Windows synchronization functions rust-lang/rust#124019)
• Updating the x86_64-pc-windows-gnu Rust toolchain installation to use its own embedded version of mingw if the version installed is outdated (not sure if feasible or helpful)
• Updating actions-rs/toolchain to warn or somehow handle the case of an old version of mingw
• Doing nothing and suggesting a workaround for anyone encountering this issue (such as using runs-on: windows-2022 instead)
• Something I hadn't thought of

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.

[ChrisDenton]

Speaking only for Rust...

Updating the x86_64-pc-windows-gnu Rust toolchain installation to use its own embedded version of mingw if the version installed is outdated (not sure if feasible or helpful)

Using the system mingw (if available) is usually preferable so I don't think this is a desirable option.

Making rustc more robust in handling older versions of mingw (which might happen as part of rust-lang/rust#124019)

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.

[v-sergei-pyshnoi]

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.

[patowen]

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.