Jens Geyer created THRIFT-6373:
----------------------------------
Summary: Move the AppVeyor MINGW job to UCRT64, as MSYS2 phases
out MINGW64
Key: THRIFT-6373
URL: https://issues.apache.org/jira/browse/THRIFT-6373
Project: Thrift
Issue Type: Improvement
Components: Build Process
Reporter: Jens Geyer
Assignee: Jens Geyer
The MINGW job in {{appveyor.yml}} builds the compiler and the C++ library with
the MINGW64 toolchain of MSYS2: {{build/appveyor/MINGW-appveyor-full.bat}}
installs the {{mingw-w64-x86_64-...}} packages and compiles with
{{/mingw64/bin/gcc.exe}}. MSYS2 announced on 2026-03-15 that it is phasing out
that environment ([MSYS2
news|https://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environment]):
{quote}
As support for Windows 8.1 has been dropped, there is no longer a need for
non-UCRT environments such as MINGW64. Consequently, we are beginning to phase
out the MINGW64 environment. To start, no new packages will be added to this
environment, and existing leaf packages may be removed if issues arise. If you
are currently relying on the MINGW64 environment, please consider switching to
UCRT64 or CLANG64 instead.
{quote}
The announcement gives no end date. The job depends on the environment in two
ways:
* It builds with MINGW64 packages: the toolchain, Boost, CMake, libevent,
OpenSSL and zlib.
* Before building, it upgrades every MSYS2 package preinstalled on the AppVeyor
image with two {{pacman -Syu}} calls. Besides the MSYS packages, that covers
the image's MINGW64 and MINGW32 packages. MSYS2 is shrinking MINGW32 as well:
its repository lists 237 packages today, against 2617 for MINGW64. When MSYS2
drops a package that the image has installed and that requires an exact version
of another package, the upgrade fails, and the job goes red before it compiles
anything.
The second case has just happened, in MINGW32. gdb 18.1 no longer builds
{{mingw-w64-i686-gdb-multiarch}}
([msys2/MINGW-packages@12db8b1|https://github.com/msys2/MINGW-packages/commit/12db8b115506331f5ca36eee23293e37185df001]).
The image has version 16.3 of it installed, which requires exactly
{{mingw-w64-i686-gdb=16.3}}. Every AppVeyor build from
[54792483|https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/builds/54792483]
(2026-09-26 20:09 UTC) to
[54792634|https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/builds/54792634]
failed in the MINGW job with:
{noformat}
error: failed to prepare transaction (could not satisfy dependencies)
:: installing mingw-w64-i686-gdb (18.1-1) breaks dependency
'mingw-w64-i686-gdb=16.3' required by mingw-w64-i686-gdb-multiarch
{noformat}
MSYS2 has since declared a conflict between the i686 gdb and the dropped
package (gdb 18.1-3,
[e3284a3|https://github.com/msys2/MINGW-packages/commit/e3284a3132495dc4c5c2a86eeed57ee1e32c2ac4]
and
[16177c9|https://github.com/msys2/MINGW-packages/commit/16177c95b5cda7d0bc0e00606e5c896ffaff01b3]).
MSYS2's pacman answers "yes" by default when it asks whether to remove a
conflicting package, so under {{--noconfirm}} the upgrade should now remove the
orphan and continue. No AppVeyor build has confirmed that yet.
h3. Proposed action
# Build the x64 MINGW job in UCRT64. Install the UCRT64 packages
({{mingw-w64-ucrt-x86_64-toolchain}}, {{mingw-w64-ucrt-x86_64-boost}} and so
on), put {{/ucrt64/bin}} first on the PATH, and point CMake at
{{/ucrt64/bin/gcc.exe}}, {{/ucrt64/bin/g++.exe}} and
{{/ucrt64/bin/mingw32-make.exe}}, with {{OPENSSL_ROOT_DIR=/ucrt64}}. UCRT64
carries the same versions of everything the job needs: GCC 16.2.0, Boost
1.92.0, CMake 4.4.3, libevent 2.1.13, OpenSSL 3.6.4 and zlib 1.3.2. The package
list also names {{mingw-w64-x86_64-toolchain}} explicitly; that entry goes. An
x86 build, which the matrix does not have, would stay in MINGW32, the only
32-bit environment MSYS2 has left.
# Stop upgrading the MINGW64 and MINGW32 packages, which the x64 job then no
longer uses, by passing {{--ignore}} patterns for both environments to the two
{{pacman -Syu}} calls. The script already passes {{%IGNORE%}} to them,
currently empty. This takes both shrinking environments out of the job's path
and shortens the download: about 250 of the 415 MiB in the last green run were
upgrades in these two environments.
# Update {{build/cmake/README-MSYS2.md}}, which also tells users to build in
MINGW64. This should be a separate change, because the file is out of date
beyond that: it passes {{WITH_SHARED_LIB}}, {{WITH_STATIC_LIB}} and
{{WITH_PERL}}, which no longer exist, and it says that libevent does not work,
while the CI job builds with libevent.
{{build/appveyor/MSYS-appveyor-full.bat}} installs MINGW64 packages as well,
but no job uses it, and it exits before reaching them.
To check the change: the MINGW job still builds the compiler and the C++
library with OpenSSL, libevent and ZLIB, and passes all 57 tests, as the last
green run on master did
([54792478|https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/builds/54792478/job/krn1yf179yfspowm],
35 minutes).
_Drafted with AI assistance (Claude Opus 5.5)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
