On 28.01.22 22:35, Marc-André Lureau wrote:
Yes, it's mingw with a different target runtime.
Until ucrt, the target was only x86/x86-64 msvcrt, so mingw32/mingw64
prefix was used. I propose to add the ucrt64 prefix for the MinGW
UCRT64 x86-64 Fedora packages. To be pedantic, we should use something
like "mingw-w64-ucrt-x86_64" as package prefix I guess. ucrt64 is a
reasonable short form. That's also what msys2 picked for their
environment (MSYSTEM) and prefix (/ucrt64)
So it's not about renaming mingw64-zlib to mingw64-msvc-zlib, and
introducing mingw64-ucrt-zlib. It's only about adding ucrt64-zlib
(progressively, package by package as needed, over time)
Ok understood.
> So what was on my mind here is that one of the attractiveness of
the
> current mingw environment is that (for a large part) you can develop the
> application on your host system, and then cross-compile the builds for
> windows, having a high confidence that the cross-compiled application
> will have the same library versions as the ones you developed and tested
> with natively. And having them pre-packaged clearly is a huge time-saver.
That's a reasonable model. But how many Windows projects out there are
tight to the Fedora release lifecycle?
A serious Windows project that needs mingw is probably built and
tested on Windows, probably using msys2 or with a custom solution.
MinGW cross-compilation on Fedora is mostly for Linux developer
convenience, and other more marginal requirements.
Would be nice to have some more
opinions of this. The reason why I'm
actually heavily involved in Fedora mingw packaging is because I do just
that - develop the applications on Linux and, in addition to the native
build, cross-compiled them for Windows, without needing any Windows
development environment. Windows testing is obviously still needed, but
for 99% of the cases, the issues found apply to both the native and the
cross-compiled binaries. So it is actually a huge time-saver.