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.
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?
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