mingw March 2026

mingw@lists.fedoraproject.org

2 participants
4 discussions

Planning to update mingw-libsoup to 3.x
by Sandro Mani 08 Mar '26

08 Mar '26

Hi Currently mingw-libsoup is still at 2.74.3, with tons of backported CVE fixes, and still many more unpatched. I'm planning to update the package to 3.6.6, the only dependent packages are mingw-libosinfo and mingw-gstreamer1-plugins-good, whose native counterparts are already being build against libsoup3. Instead of retiring mingw-libsoup and submitting mingw-libsoup3 for review, I'd just update the mingw-libsoup package directly to 3.x. Any objections? Scratch build is here [1]. Thanks Sandro [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=143131992

1 0

Replace zlib with zlib-ng, minizip with minizip-ng
by Zephyrus Lykos 08 Mar '26

08 Mar '26

This is a follow-up on the already landed https://fedoraproject.org/wiki/Changes/ZlibNGTransition + https://fedoraproject.org/wiki/Changes/MinizipNGTransition Provide the ng package and a compat package; use ng interfaces whenever possible. Possibly needs a large rebuild.

3 3

Provide LLVM libcxx builds for MinGW
by Zephyrus Lykos 01 Mar '26

01 Mar '26

For binary compatibility with MSYS2's CLANG64 & CLANGARM64 environment.

2 1

UCRT, Additional Toolchains and Lowering the Support Tier for MSVCRT
by Zephyrus Lykos 01 Mar '26

01 Mar '26

Hi all, Since most upstream projects (mingw-w64, Wine, Mono, Microsoft SDKs, and .NET) switched to the UCRT runtime by default, I propose we also follow their choice on Fedora's side. This should not break most OS support, since: - XP: The vcredist installer automatically deploys UCRT stub DLLs (apisetstub). - Vista ~ 8.1: API Set resolution implemented in NTDLL. UCRT is available as system update packages (KB2999226). - 10 and onwards: Integrated in the base OS. Any OS preceding XP will not be supported with UCRT. If people want their executables to work without installing UCRT, they need to ship the redistributable binaries (apisetstub + ucrtbase.dll) from MS's SDK, located in: C:\Program Files (x86)\Windows Kits\10\Redist\%SDKVER%\ucrt\DLLs\ like how one has to ship msvcp##.dll for builds linking with CRT other than libmsvcrt-os.a. Read mingw-w64-doc/howto-build/crt-libraries.txt for more info. --- Many projects now want a Windows on ARM target. We'd also like to build Wine using Fedora's toolchain and libraries. This could be the opportunity to add the toolchain for ucrtarm and ucrtarm64 (names TBD). The toolchain might need a patched GCC and binutils; please see the patchsets at https://github.com/Windows-on-ARM-Experiments. Otherwise we could use Clang, like what MSYS2 does now. However, we don't want to default to libc++, unlike MSYS2. We might or might not want to add a target for ARMNT (32-bit ARM on Windows): Good: Wine and Wine Mono have ARMNT and WoW support, which requires a toolchain. Bad: Microsoft already sunsetted their support. SDK 26100 removed ARM32 libraries, and OS 26100^ removed ARM32 UWP app support. There isn't support for ARMNT in GCC/binutils. Fedora doesn't target 32-bit ARM. We also don't have CONFIG_COMPAT=y on all flavors of kernel. ^: actually should be an earlier canary build, but i forgor Additionally, there could be support for generating code with ARM64EC ABI (https://learn.microsoft.com/en-us/windows/arm/arm64ec) This can be further improved by producing CHPEV2 fat binaries (https://learn.microsoft.com/en-us/windows/arm/arm64x-pe) LLVM should already have preliminary support for ARM64EC codegen and ARM64X linking in llvm-21, but GCC and binutils still do not have much support. --- We might also want to lower the support tier for MSVCRT or just drop it. Otherwise, we will have too many targets to maintain.

4 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw March 2026