mingw

mingw@lists.fedoraproject.org

2 participants
5916 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

Major Refactoring for Wine Mono
by Zephyrus Lykos 25 Feb '26

25 Feb '26

1. WpfGfx support I've got WpfGfx to build with libstdc++: https://gitlab.winehq.org/mono/wpf/-/merge_requests/8. GCC produces ICE, and I have no time to troubleshoot; Clang works fine. 2. Unbundle many dependencies, remove prebuilt binaries Already unbundled: FAudio^, SDL3 (unmanaged side; still need to unbundle the managed side via codegen) Trivial TODOs: FNA3D^ TODO: Mono.Cecil TODO: remove unused sources in the tarball to ensure they're actually unused. ^: Need to add a csharp subpackage providing mono(...) from the native Unix side. Since DllImport does not care about platform differences, we can just copy or symlink them. 3. Split package Support installing x86/x86_64 individually. 4. Apply patches from rpms/mono --- Wishlist: Add ARM/AArch64 support. Remove prebuilt reference assemblies?

1 0

Re: Updating boost
by Richard W.M. Jones 21 Feb '26

21 Feb '26

On Fri, Feb 20, 2026 at 09:26:29PM +0000, Jonathan Wakely wrote: > On Fri, 20 Feb 2026 at 21:08, Richard W.M. Jones <rjones(a)redhat.com> wrote: > > > > On Fri, Feb 20, 2026 at 02:24:57PM -0500, Neal Gompa wrote: > > > I could try to look into updating this, but I'll need some help to > > > figure out how to get all the revdeps rebuilt and such. Do we want to > > > try to merge this into the main boost spec? Or keep it separate? > > > > It'd be ideal to merge it since it reduces long term maintenance, but > > that's going to require both the cooperation and the understanding of > > Fedora's boost maintainer. > > What's the context here? Merge what? At the moment, nothing more than discussion. For some packages we've combined the mingw-* [Windows] package with the main package (so the mingw-* package is built as a subpackage from the same sources). An example is worth a 1000 words, so: https://src.fedoraproject.org/rpms/gnutls/blob/rawhide/f/gnutls.spec (look for the 'with mingw' sections). Advantages are that the packages always stay in sync, and there's less maintenance (at least, in total). Disadvantages is this puts extra burden on the main maintainer. For some packages it might be a very great extra burden, for others not so much. It also makes the spec file a lot more complicated. Since the mingw-boost package has fallen some way behind the main package, that's what we were discussing. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

2 13

Updating boost
by Albert Astals Cid 20 Feb '26

20 Feb '26

Hi, i see that https://src.fedoraproject.org/rpms/mingw-boost is stuck at boost 1.78 while https://src.fedoraproject.org/rpms/boost has newer versions. Could it be updated? (Including Fedora 44 if possible) Cheers, Albert

3 5

Updating libtiff
by Albert Astals Cid 22 Dec '25

22 Dec '25

Hi, i see that https://src.fedoraproject.org/rpms/mingw-libtiff is stuck at libtiff 4.4 while https://src.fedoraproject.org/rpms/libtiff has newer versions. Could it be updated? Cheers, Albert

3 5

Help with conversion to native build
by Richard Shaw 15 Jul '25

15 Jul '25

I'm working on a PR for libsamplerate to build native MinGW packages. Initially I stuck with the autotools build but for some reason '-z' was sneaking into the LDFLAGS and I couldn't figure out how to remove it. So then I decided to transition to a CMake build which is working including tests, the problem is even though I have the macros in the spec file per the guidelines, the debuginfo stuff seems to be missing. Can someone take a look? https://src.fedoraproject.org/fork/hobbes1069/rpms/libsamplerate/c/9199ef8a… Thanks, Richard

2 1

GCC 15 is not working for Wine-Mono
by Michael Cronenworth 30 May '25

30 May '25

Hello, I needed to upgrade wine-mono for Wine 10.5 released last week. The builds for F42 and prior succeed. The build for Rawhide fails. Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=131200142 Error seen in build.log: make[1]: Entering directory '/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/build/FNAMF-x86' i686-w64-mingw32-gcc -o debug.o -D_WIN32_WINNT=0x0602 -D__WINESRC__ --std=c99 -c -Wall -Wno-format -Werror -gcodeview -g -I/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/../.. -I/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/../../wine /builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/../../wine/debug.c make[1]: Leaving directory '/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/build/FNAMF-x86' /tmp/ccREFp1H.s: Assembler messages: /tmp/ccREFp1H.s:6104: Error: can't resolve .debug$T - Ltext0 /tmp/ccREFp1H.s:8549: Error: can't resolve .debug$T - Ltext0 make[1]: *** [/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/Makefile:15: debug.o] Error 1 Is this a known issue? Thanks, Michael

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw