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.