[
https://issues.apache.org/jira/browse/THRIFT-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119832#comment-18119832
]
Jens Geyer commented on THRIFT-6373:
------------------------------------
The fix in MSYS2's gdb 18.1-3 is confirmed on the AppVeyor image. The full
upgrade printed the following line in two builds:
*
[54793919|https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/builds/54793919],
the first push of [PR #3954|https://github.com/apache/thrift/pull/3954], with
the {{pacman -Syu}} calls still as on master;
*
[54793977|https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/builds/54793977],
[PR #3955|https://github.com/apache/thrift/pull/3955], on master's unchanged
MINGW64 script.
{noformat}
:: mingw-w64-i686-gdb-18.1-3 and mingw-w64-i686-gdb-multiarch-16.3-1 are in
conflict. Remove mingw-w64-i686-gdb-multiarch? [Y/n]
{noformat}
In both builds the upgrade took the default yes, and the MINGW job passed.
Items 1 and 2 were merged with PR #3954 as
[f9b508e74|https://github.com/apache/thrift/commit/f9b508e74ec345fdc89418c38a275bc4b13dd5c8].
Item 3 continues in THRIFT-6390.
A correction to the description: {{WITH_SHARED_LIB}} and {{WITH_STATIC_LIB}}
have not gone. CMake still accepts them and warns that they are deprecated in
favour of {{BUILD_SHARED_LIBS}}. {{WITH_PERL}} is the only one that is not a
CMake option.
_Drafted with AI assistance (Claude Opus 5.5)._
> 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
> Priority: Major
> Fix For: 0.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
