https://fedoraproject.org/wiki/Changes/F37MingwUCRT
== Summary ==
This proposal is to add the UCRT target & support from Fedora to the MinGW cross-toolchains.
== Owner == * Name: [[User:elmarco| Marc-André Lureau]] * Email: marcandre.lureau@redhat.com
== Detailed Description ==
The current mingw32 and mingw64 cross-toolchains provided by Fedora target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio 15 & Windows 10, the default and recommended runtime is UCRT. See also [https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT vs UCRT].
A new toolchain target triple `x86_64-w64-mingw32ucrt` and associated binaries will be added.
Fedora MinGW macros will be provided to target UCRT, with ucrt64-* prefix (ex: `ucrt64-meson`)
mingw-* libraries will be progressively adjusted to add the produced ucrt64-* binaries.
Since mingw-*.spec are very repetitive and cumbersome to modify (each mingw32, mingw64, ucrt package has to be defined manually, and this is tedious and error-prone), a custom MinGW/Fedora tool or solution will be proposed. In the meantime, packages can be modified to add manually the new target.
[https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org/... UCRT plans on mingw@lists.fedoraproject.org ]
== Benefit to Fedora ==
This change will allow to cross-compile projects to Windows with the up to date C runtime & headers, and better c99 support. This should allow to more easily mix binaries produced from different versions or compilers as well.
== Scope ==
* Proposal owners: ** update the mingw filesystem, binutils, headers, gcc & winpthreads packages ** bootstrap the new toolchain ** propose a solution to simplify library packaging with the different targets ** update some common library packages, such as mingw-zlib * Other developers: ** Progressively adjust the mingw-* packages to produce ucrt64- packages, following the updated guidelines. * Release engineering: * Policies and guidelines: https://fedoraproject.org/wiki/Packaging:MinGW packaging guideline will be adjusted. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives:
== Upgrade/compatibility impact ==
None
== How To Test ==
<pre> $ x86_64-w64-mingw32ucrt-gcc test.c
$ /usr/bin/mingw-objdump -p a.exe | grep DLL vma: Hint Time Forward DLL First DLL Name: KERNEL32.dll DLL Name: api-ms-win-crt-time-l1-1-0.dll DLL Name: api-ms-win-crt-math-l1-1-0.dll DLL Name: api-ms-win-crt-runtime-l1-1-0.dll DLL Name: api-ms-win-crt-environment-l1-1-0.dll DLL Name: api-ms-win-crt-private-l1-1-0.dll DLL Name: api-ms-win-crt-heap-l1-1-0.dll DLL Name: api-ms-win-crt-locale-l1-1-0.dll DLL Name: api-ms-win-crt-stdio-l1-1-0.dll DLL Name: api-ms-win-crt-string-l1-1-0.dll </pre>
== User Experience ==
Windows binaries produced by Fedora cross-toolchain will target a more modern and compatible C runtime, bringing hopefully better compatibility & safety.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The new MinGW toolchain and tools are available to compile binaries targeting the Windows UCRT.
On Sat, Jan 29, 2022 at 12:32 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
== Summary ==
This proposal is to add the UCRT target & support from Fedora to the MinGW cross-toolchains.
== Owner ==
- Name: [[User:elmarco| Marc-André Lureau]]
- Email: marcandre.lureau@redhat.com
== Detailed Description ==
The current mingw32 and mingw64 cross-toolchains provided by Fedora target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio 15 & Windows 10, the default and recommended runtime is UCRT. See also [https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT vs UCRT].
A new toolchain target triple `x86_64-w64-mingw32ucrt` and associated binaries will be added.
Fedora MinGW macros will be provided to target UCRT, with ucrt64-* prefix (ex: `ucrt64-meson`)
mingw-* libraries will be progressively adjusted to add the produced ucrt64-* binaries.
Since mingw-*.spec are very repetitive and cumbersome to modify (each mingw32, mingw64, ucrt package has to be defined manually, and this is tedious and error-prone), a custom MinGW/Fedora tool or solution will be proposed. In the meantime, packages can be modified to add manually the new target.
[https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org/... UCRT plans on mingw@lists.fedoraproject.org ]
== Benefit to Fedora ==
This change will allow to cross-compile projects to Windows with the up to date C runtime & headers, and better c99 support. This should allow to more easily mix binaries produced from different versions or compilers as well.
== Scope ==
- Proposal owners:
** update the mingw filesystem, binutils, headers, gcc & winpthreads packages ** bootstrap the new toolchain ** propose a solution to simplify library packaging with the different targets ** update some common library packages, such as mingw-zlib
- Other developers:
** Progressively adjust the mingw-* packages to produce ucrt64- packages, following the updated guidelines.
- Release engineering:
- Policies and guidelines:
https://fedoraproject.org/wiki/Packaging:MinGW packaging guideline will be adjusted.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
== Upgrade/compatibility impact ==
None
== How To Test ==
<pre> $ x86_64-w64-mingw32ucrt-gcc test.c $ /usr/bin/mingw-objdump -p a.exe | grep DLL vma: Hint Time Forward DLL First DLL Name: KERNEL32.dll DLL Name: api-ms-win-crt-time-l1-1-0.dll DLL Name: api-ms-win-crt-math-l1-1-0.dll DLL Name: api-ms-win-crt-runtime-l1-1-0.dll DLL Name: api-ms-win-crt-environment-l1-1-0.dll DLL Name: api-ms-win-crt-private-l1-1-0.dll DLL Name: api-ms-win-crt-heap-l1-1-0.dll DLL Name: api-ms-win-crt-locale-l1-1-0.dll DLL Name: api-ms-win-crt-stdio-l1-1-0.dll DLL Name: api-ms-win-crt-string-l1-1-0.dll </pre>
== User Experience ==
Windows binaries produced by Fedora cross-toolchain will target a more modern and compatible C runtime, bringing hopefully better compatibility & safety.
== Dependencies ==
None
== Contingency Plan ==
- Contingency mechanism: N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? No (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The new MinGW toolchain and tools are available to compile binaries targeting the Windows UCRT.
I like this, I wonder if it makes sense to do something like how kernel module packaging works with kmodtool and things to generate subpackages for all the variants and have macros to trigger builds for all flavors...
-- 真実はいつも一つ！/ Always, there's only one truth!
Ben Cotton wrote:
The current mingw32 and mingw64 cross-toolchains provided by Fedora target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio 15 & Windows 10, the default and recommended runtime is UCRT. See also [https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT vs UCRT].
A new toolchain target triple `x86_64-w64-mingw32ucrt` and associated binaries will be added.
Fedora MinGW macros will be provided to target UCRT, with ucrt64-* prefix (ex: `ucrt64-meson`)
mingw-* libraries will be progressively adjusted to add the produced ucrt64-* binaries.
UCRT is 64-bit only?
Kevin Kofler
For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
MSVCRT […] Works out of the box on every Microsoft Windows versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. The original Windows 95, with or without the only service pack released for it (SP1, because OSR 2 was not released as a service pack, only as an "OEM service release" for new computers), shipped only the even older CRTDLL.DLL (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had to be installed through a redistributable (which was included with many applications including Microsoft Office, but it was not part of the operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
Kevin Kofler
On Mon, Jan 31, 2022 at 05:17:29PM +0100, Kevin Kofler via devel wrote:
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
I've just checked, Windows 10 was released 7 years ago (Fedora 22 timeframe). We don't have to care about compatibility with so ancient releases.
Tomasz Torcz tomek@pipebreaker.pl wrote:
On Mon, Jan 31, 2022 at 05:17:29PM +0100, Kevin Kofler via devel wrote:
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
I've just checked, Windows 10 was released 7 years ago (Fedora 22 timeframe). We don't have to care about compatibility with so ancient releases.
Not Windows 95, sure, but the Windows world moves at a much slower pace than Fedora, especially among non-technical users. Windows 7 and 8 are still out there. Even XP.
That's why I consider the 32-bit MSVCRT binary the primary release of my Windows software: I can be sure it'll run on whatever ancient system it might end up on.
Ron
Hi
On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
MSVCRT […] Works out of the box on every Microsoft Windows versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. The original Windows 95, with or without the only service pack released for it (SP1, because OSR 2 was not released as a service pack, only as an "OEM service release" for new computers), shipped only the even older CRTDLL.DLL (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had to be installed through a redistributable (which was included with many applications including Microsoft Office, but it was not part of the operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today.
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
But there is at least one user that may legitimately want to keep a msvcrt 32bit target: mingw-wine-gecko.
On Fri, Feb 4, 2022 at 8:21 AM Marc-André Lureau marcandre.lureau@gmail.com wrote:
Hi
On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
MSVCRT […] Works out of the box on every Microsoft Windows versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. The original Windows 95, with or without the only service pack released for it (SP1, because OSR 2 was not released as a service pack, only as an "OEM service release" for new computers), shipped only the even older CRTDLL.DLL (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had to be installed through a redistributable (which was included with many applications including Microsoft Office, but it was not part of the operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today.
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
But there is at least one user that may legitimately want to keep a msvcrt 32bit target: mingw-wine-gecko.
Unfortunately, there hasn't been a ton of incentive for Windows developers to switch to 64-bit. Heck, Visual Studio itself only switched a couple of years ago.
A lot of the extended Windows dev ecosystem hasn't gotten to 64-bit either, yet :(
I think it's good to have the UCRT target, but dropping the existing ones would be extremely painful.
On 2/4/22 7:20 AM, Marc-André Lureau wrote:
But there is at least one user that may legitimately want to keep a msvcrt 32bit target: mingw-wine-gecko.
I saw a reference[1] to a 32-bit UCRT build so it may be possible to switch over, but it may require some work.
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote:
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
This isn't a very useful suggestion. We build using mingw precisely to avoid touching Windows at all.
I'm a little confused about the thread though. If we use mingw32-* after this change, does it still use msvcrt?
Rich.
Hi
On Sat, Feb 5, 2022 at 2:44 AM Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote:
Projects releasing for Windows should probably natively build and test
their
releases with Msys2, and they can do so for msvcrt targets.
This isn't a very useful suggestion. We build using mingw precisely to avoid touching Windows at all.
Even freedesktop offers Windows CI instances where you can build natively.
I have honest doubts about projects doing releases for Windows without ever running it.
I'm a little confused about the thread though. If we use mingw32-* after this change, does it still use msvcrt?
There is no change on the existing mingw32 and mingw64 targets. Did you read the proposal? :)
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, Feb 05, 2022 at 01:27:48PM +0400, Marc-André Lureau wrote:
Hi
On Sat, Feb 5, 2022 at 2:44 AM Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > Projects releasing for Windows should probably natively build and test their > releases with Msys2, and they can do so for msvcrt targets. This isn't a very useful suggestion. We build using mingw precisely to avoid touching Windows at all.Even freedesktop offers Windows CI instances where you can build natively.
I have honest doubts about projects doing releases for Windows without ever running it.
This isn't what I said - we don't want to use Windows to build the package (rhsrvany is the package in this case). We do test it in a Windows VM before release. If it were to fail -- I don't recall it ever failing actually, so this is theoretical -- then we'd go back to the Fedora mingw environment to fix it. What I don't want is to have to use a Windows environment to build the package.
I'm a little confused about the thread though. If we use mingw32-* after this change, does it still use msvcrt?There is no change on the existing mingw32 and mingw64 targets. Did you read the proposal? :)
I did read it yes, but later messages in the thread confused things. If we're not touching the mingw32 target, at least for now, then that's fine. Eventually I guess when absolutely no one is using Windows 7 and doesn't want to use V2V to convert those guests we can drop the 32 bit / msvcrt stuff.
Rich.
On Sat, Feb 05, 2022 at 10:47:12AM +0100, Kevin Kofler via devel wrote:
Marc-André Lureau wrote:
I have honest doubts about projects doing releases for Windows without ever running it.
WINE can be helpful for testing, or I can just let those Windows users who asked for the Windows build to begin with test it. ;-)
I agree, this is perfectly sensible for Fedora.
Although I wish Wine would add support for Windows 10 AF_UNIX so I could test my nbdkit builds for Windows :-/
Rich.
On Sat, Feb 5, 2022 at 5:54 AM Richard W.M. Jones rjones@redhat.com wrote:
On Sat, Feb 05, 2022 at 10:47:12AM +0100, Kevin Kofler via devel wrote:
Marc-André Lureau wrote:
I have honest doubts about projects doing releases for Windows without ever running it.
WINE can be helpful for testing, or I can just let those Windows users who asked for the Windows build to begin with test it. ;-)
I agree, this is perfectly sensible for Fedora.
Although I wish Wine would add support for Windows 10 AF_UNIX so I could test my nbdkit builds for Windows :-/
Is there a bug with Wine for that? It'd be useful for me too and I'd like to track progress on that...
On Sat, Feb 05, 2022 at 05:57:10AM -0500, Neal Gompa wrote:
On Sat, Feb 5, 2022 at 5:54 AM Richard W.M. Jones rjones@redhat.com wrote:
On Sat, Feb 05, 2022 at 10:47:12AM +0100, Kevin Kofler via devel wrote:
Marc-André Lureau wrote:
I have honest doubts about projects doing releases for Windows without ever running it.
WINE can be helpful for testing, or I can just let those Windows users who asked for the Windows build to begin with test it. ;-)
I agree, this is perfectly sensible for Fedora.
Although I wish Wine would add support for Windows 10 AF_UNIX so I could test my nbdkit builds for Windows :-/
Is there a bug with Wine for that? It'd be useful for me too and I'd like to track progress on that...
No I didn't get round to that.
I did write a patch for it though. Latest version is: https://www.winehq.org/pipermail/wine-devel/2021-May/187049.html
Rich.
Am 04.02.22 um 23:43 schrieb Richard W.M. Jones:
We build using mingw precisely to avoid touching Windows at all.
Yup - same here. We are using Fedora's mingw packages to create Windows executables which link to a proprietary 32 bit library. This really has been a huge time saver for me and I would really like to keep that ability.
Felix
Marc-André Lureau wrote:
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
Well, with cross-MinGW and cross-NSIS, I can package software for Windows without ever touching a Windows machine. I have done so more than once already. I do not even have a Windows installation on which I can run Msys2.
Kevin Kofler
On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote:
Marc-André Lureau wrote:
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
Well, with cross-MinGW and cross-NSIS, I can package software for Windows without ever touching a Windows machine. I have done so more than once already. I do not even have a Windows installation on which I can run Msys2.
Exactly, this is the precise reason why a group of us started the Fedora mingw packaging effort all those years ago.
I have a Windows machine for testing / debugging on, but it is so much simpler if we can do cross builds from Linux, as it means we don't have to switch context between machines when developing.
I rather wish we had full cross build facilities for all Fedora arches in fact. As well as for Mingw, upstream we cross build libvirt / QEMU for all non-x86 arches too by simplying having a set of containers populated with all the relevant cross compilers and foreign libraries. While we can use Fedora for our Mingw cross targets, we have to use Debian for all the Linux non-x86 targets.
It is very compelling to be able to just run things like
make docker-build@debian-ppc64el-cross
make docker-build@fedora-win32-cross
giving throwaway container buildroots, instead of having to deal with full VM installs.
Regards, Daniel
Hi
On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote:
Marc-André Lureau wrote:
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in
the
future.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
Well, with cross-MinGW and cross-NSIS, I can package software for
Windows
without ever touching a Windows machine. I have done so more than once already. I do not even have a Windows installation on which I can run
Msys2.
Exactly, this is the precise reason why a group of us started the Fedora mingw packaging effort all those years ago.
I have a Windows machine for testing / debugging on, but it is so much simpler if we can do cross builds from Linux, as it means we don't have to switch context between machines when developing.
Nowadays, with the built-in ssh server, git, msys2, meson, docker and CI..., developing for Windows is much easier than it was 10y ago!
For me, it's barely a context switch, sync the repo and run "meson test" (or cmake) there. I haven't tried the shared folder yet. Testing the windows build is not something you can really do on Linux... So I will prefer a native build whenever possible.
Anyway, no need to convince me about the need for cross-compilers :) However, I regret that we have undermaintained and duplicated mingw*-pkg. I am looking at whether we can use msys2 packages instead (for developpers).
I rather wish we had full cross build facilities for all Fedora arches in fact. As well as for Mingw, upstream we cross build libvirt / QEMU for all non-x86 arches too by simplying having a set of containers populated with all the relevant cross compilers and foreign libraries. While we can use Fedora for our Mingw cross targets, we have to use Debian for all the Linux non-x86 targets.
It is very compelling to be able to just run things like
make docker-build@debian-ppc64el-cross
make docker-build@fedora-win32-cross
giving throwaway container buildroots, instead of having to deal with full VM installs.
I also wish we would have more cross-compilers available. I imagine with use of container/namespaces, the target Fedora sys-root could be simply mounted in a well-known location (instead of duplicating packages, or developing a rpm multi-arch solution)
On Mon, Feb 07, 2022 at 01:29:45PM +0400, Marc-André Lureau wrote:
Hi
On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote:
Marc-André Lureau wrote:
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in
the
future.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
Well, with cross-MinGW and cross-NSIS, I can package software for
Windows
without ever touching a Windows machine. I have done so more than once already. I do not even have a Windows installation on which I can run
Msys2.
Exactly, this is the precise reason why a group of us started the Fedora mingw packaging effort all those years ago.
I have a Windows machine for testing / debugging on, but it is so much simpler if we can do cross builds from Linux, as it means we don't have to switch context between machines when developing.
Nowadays, with the built-in ssh server, git, msys2, meson, docker and CI..., developing for Windows is much easier than it was 10y ago!
That's an entire second OS and suite of development tools to maintain on an ongoing basis. If you're working on this every day, maybe that's a worthwhile investment, but for most developers that's not at all compelling.
Regards, Daniel
On 07.02.22 10:29, Marc-André Lureau wrote:
Hi
On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote: > Marc-André Lureau wrote: > > Fwiw, given that the primary use case for a cross-toolchain is for > > developer needs, I think it is reasonable to have only UCRT target in the > > future. > > > > Projects releasing for Windows should probably natively build and test > > their releases with Msys2, and they can do so for msvcrt targets. > > Well, with cross-MinGW and cross-NSIS, I can package software for Windows > without ever touching a Windows machine. I have done so more than once > already. I do not even have a Windows installation on which I can run Msys2. Exactly, this is the precise reason why a group of us started the Fedora mingw packaging effort all those years ago. I have a Windows machine for testing / debugging on, but it is so much simpler if we can do cross builds from Linux, as it means we don't have to switch context between machines when developing.Nowadays, with the built-in ssh server, git, msys2, meson, docker and CI..., developing for Windows is much easier than it was 10y ago!
For me, it's barely a context switch, sync the repo and run "meson test" (or cmake) there. I haven't tried the shared folder yet. Testing the windows build is not something you can really do on Linux... So I will prefer a native build whenever possible.
Anyway, no need to convince me about the need for cross-compilers :) However, I regret that we have undermaintained and duplicated mingw*-pkg. I am looking at whether we can use msys2 packages instead (for developpers).
As noted in the mingw list thread, for me the objective of version parity between native and mingw packages of the current mingw-environment is a big selling point. My real-world experience reflects what others shared in this post, namely that by far most issues which pop up during testing are target independent, i.e. will affect both the native build as the cross-compiled build. It's true that version partiy is not 100% reflected in the current package state, but I still believe the overall state is pretty good, and personally I'd rather look at building cross and native packages from the same spec to reduce the maintenance burden. I know that there was a proposal in this direction some months ago, I'd like to start moving in this direction at least with packages where I maintain both the native and the cross packages.
Sandro
On Mon, Feb 07, 2022 at 10:50:00AM +0100, Sandro Mani wrote:
On 07.02.22 10:29, Marc-André Lureau wrote:
Hi
On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote: > Marc-André Lureau wrote: > > Fwiw, given that the primary use case for a cross-toolchain is for > > developer needs, I think it is reasonable to have only UCRT target in the > > future. > > > > Projects releasing for Windows should probably natively build and test > > their releases with Msys2, and they can do so for msvcrt targets. > > Well, with cross-MinGW and cross-NSIS, I can package software for Windows > without ever touching a Windows machine. I have done so more than once > already. I do not even have a Windows installation on which I can run Msys2. Exactly, this is the precise reason why a group of us started the Fedora mingw packaging effort all those years ago. I have a Windows machine for testing / debugging on, but it is so much simpler if we can do cross builds from Linux, as it means we don't have to switch context between machines when developing.Nowadays, with the built-in ssh server, git, msys2, meson, docker and CI..., developing for Windows is much easier than it was 10y ago!
For me, it's barely a context switch, sync the repo and run "meson test" (or cmake) there. I haven't tried the shared folder yet. Testing the windows build is not something you can really do on Linux... So I will prefer a native build whenever possible.
Anyway, no need to convince me about the need for cross-compilers :) However, I regret that we have undermaintained and duplicated mingw*-pkg. I am looking at whether we can use msys2 packages instead (for developpers).
As noted in the mingw list thread, for me the objective of version parity between native and mingw packages of the current mingw-environment is a big selling point. My real-world experience reflects what others shared in this post, namely that by far most issues which pop up during testing are target independent, i.e. will affect both the native build as the cross-compiled build. It's true that version partiy is not 100% reflected in the current package state, but I still believe the overall state is pretty good, and personally I'd rather look at building cross and native packages from the same spec to reduce the maintenance burden. I know that there was a proposal in this direction some months ago, I'd like to start moving in this direction at least with packages where I maintain both the native and the cross packages.
Yes, I proposed that last year. I was supposed to move it forward by providing a copr repo illustrating it in real world, but I'm afraid I got side tracked.
Regards, Daniel
As noted in the mingw list thread, for me the objective of version parity between native and mingw packages of the current mingw-environment is a big selling point. My real-world experience reflects what others shared in this post, namely that by far most issues which pop up during testing are target independent, i.e. will affect both the native build as the cross-compiled build. It's true that version partiy is not 100% reflected in the current package state, but I still believe the overall state is pretty good, and personally I'd rather look at building cross and native packages from the same spec to reduce the maintenance burden. I know that there was a proposal in this direction some months ago, I'd like to start moving in this direction at least with packages where I maintain both the native and the cross packages.
Yes, I proposed that last year. I was supposed to move it forward by providing a copr repo illustrating it in real world, but I'm afraid I got side tracked.
I also wasn't able to participate in the discussion having had too much going on then, but I'd be happy to help (re-)launching the effort.
Sandro
On 07.02.22 11:07, Sandro Mani wrote:
As noted in the mingw list thread, for me the objective of version parity between native and mingw packages of the current mingw-environment is a big selling point. My real-world experience reflects what others shared in this post, namely that by far most issues which pop up during testing are target independent, i.e. will affect both the native build as the cross-compiled build. It's true that version partiy is not 100% reflected in the current package state, but I still believe the overall state is pretty good, and personally I'd rather look at building cross and native packages from the same spec to reduce the maintenance burden. I know that there was a proposal in this direction some months ago, I'd like to start moving in this direction at least with packages where I maintain both the native and the cross packages.
Yes, I proposed that last year. I was supposed to move it forward by providing a copr repo illustrating it in real world, but I'm afraid I got side tracked.
I also wasn't able to participate in the discussion having had too much going on then, but I'd be happy to help (re-)launching the effort.
I'd like to start working on this with some of my packages, I'd handle this similarly to say mpi builds, just manually adding the required steps in %build and %install and adding subpackages as necessary, then retiring the respective mingw repo. Any objections to this?
Sandro
On Thu, Feb 10, 2022 at 10:29:14AM +0100, Sandro Mani wrote:
On 07.02.22 11:07, Sandro Mani wrote:
Yes, I proposed that last year. I was supposed to move it forward by providing a copr repo illustrating it in real world, but I'm afraid I got side tracked.
I also wasn't able to participate in the discussion having had too much going on then, but I'd be happy to help (re-)launching the effort.
I'd like to start working on this with some of my packages, I'd handle this similarly to say mpi builds, just manually adding the required steps in %build and %install and adding subpackages as necessary, then retiring the respective mingw repo. Any objections to this?
FWIW, my proof of concept last year did the following to the libvirt-glib.spec file:
https://gitlab.com/berrange/libvirt-glib/-/commit/45994bf93bb4b030e3ab57c9b2...
As you can tell, it is essentially just the contents of the current mingw-libvirt-glib.spec file:
https://gitlab.com/berrange/libvirt-glib/-/blob/mingw-rpm-merge2/mingw-libvi...
copied over into the libvirt-glib.spec
To repeat my previously reported interesting notes:
* We need to set mingw32_pkg_name/mingw64_pkg_name explicitly because the current logic that sets these doesn't work:
%mingw32_pkg_name %(echo %{name} | sed 's/^mingw-/mingw32-/')
Presumably we can fix that macro so that it does the right thing when no mingw- prefix exists in the first place
* We can't use %mingw_package_header because that splatters the native debuginfo generation. So we must explicitly add mingw debuginfo packages by referencing
%{?mingw_debug_package}
and at end of %install add
%mingw_debug_install_post
* %mingw_package_header has reference to overriding strip/objdump to prevent corruption of binaries. We can't do that override because we need native strip/objdump for the native builds.
AFAICT though, no corruption happened to my DLLs even without this strip/objdump override. Looks like this caveat might be obsolete, unless the scenarios it hits are more niche than I tested.
* %mingw_package_header tries to disable the internal dependancy generator on RHEL 6. For reasons I don't understand, it ends up disabling it on Fedora too.
%mingw_package_header \ %global __strip %{mingw_strip} \ %global __objdump %{mingw_objdump} \ %if 0%{?rhel} == 6 \ %global _use_internal_dependency_generator 0 \ %global __find_requires %{mingw_findrequires} \ %global __find_provides %{mingw_findprovides} \ %endif \ %global __debug_install_post %%{mingw_debug_install_post} \ %{nil}
The last two points feel like simple bugs we need to fix regardless.
Regards, Daniel
On 10.02.22 11:13, Daniel P. Berrangé wrote:
FWIW, my proof of concept last year did the following to the libvirt-glib.spec file:
https://gitlab.com/berrange/libvirt-glib/-/commit/45994bf93bb4b030e3ab57c9b2...
As you can tell, it is essentially just the contents of the current mingw-libvirt-glib.spec file:
https://gitlab.com/berrange/libvirt-glib/-/blob/mingw-rpm-merge2/mingw-libvi...
copied over into the libvirt-glib.spec
To repeat my previously reported interesting notes:
We need to set mingw32_pkg_name/mingw64_pkg_name explicitly because the current logic that sets these doesn't work:
%mingw32_pkg_name %(echo %{name} | sed 's/^mingw-/mingw32-/')
Presumably we can fix that macro so that it does the right thing when no mingw- prefix exists in the first place
Right, I'd suggest changing this to
%mingw32_pkg_name %(echo %{name} |sed -E 's/^(mingw-|)/mingw32-/')
We can't use %mingw_package_header because that splatters the native debuginfo generation. So we must explicitly add mingw debuginfo packages by referencing
%{?mingw_debug_package}
and at end of %install add
%mingw_debug_install_post
I guess this is acceptable.
%mingw_package_header has reference to overriding strip/objdump to prevent corruption of binaries. We can't do that override because we need native strip/objdump for the native builds.
AFAICT though, no corruption happened to my DLLs even without this strip/objdump override. Looks like this caveat might be obsolete, unless the scenarios it hits are more niche than I tested.
Thanks, I'll look out for these.
%mingw_package_header tries to disable the internal dependancy generator on RHEL 6. For reasons I don't understand, it ends up disabling it on Fedora too.
%mingw_package_header \ %global __strip %{mingw_strip} \ %global __objdump %{mingw_objdump} \ %if 0%{?rhel} == 6 \ %global _use_internal_dependency_generator 0 \ %global __find_requires %{mingw_findrequires} \ %global __find_provides %{mingw_findprovides} \ %endif \ %global __debug_install_post %%{mingw_debug_install_post} \ %{nil}
I actually already dropped this from mingw-filesystem (see https://src.fedoraproject.org/rpms/mingw-filesystem/c/f6cc2b6d756f8201c3119b...)
Thanks Sandrô
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote:
Hi
On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
MSVCRT […] Works out of the box on every Microsoft Windows versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. The original Windows 95, with or without the only service pack released for it (SP1, because OSR 2 was not released as a service pack, only as an "OEM service release" for new computers), shipped only the even older CRTDLL.DLL (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had to be installed through a redistributable (which was included with many applications including Microsoft Office, but it was not part of the operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today.
There's a variety of sites claiming to have stats on different Windows versions. They all show Windows 10 with the majority, but disagree on just how much older stuff still gets used. As one example though, this shows Windows 7 with 12 % and Windows 8.1 on 3 %. That 15% is too significant to declare that MSVCRT is deprecated yet.
https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future.
At some point off in the future maybe, but we would need to see the stats for older Windows 7/8 releases drop significantly lower than they are today.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
Testing yes, but building no. I do all Windows builds using Fedora cross compilation, using pristine mock chroots. The idea of building under Msys2 on a Windows machine I now have to maintain in a pristine condition, is not at all appealing. I don't want to have to figure out a different way to build that's equivalent to what mock offers me. It is much more appealing to have a single machine from which I can do both Linux and Windows builds using the same basic infra for both
Regards, Daniel
Hi
On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote:
Hi
On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
MSVCRT […] Works out of the box on every Microsoft Windows versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR
The original Windows 95, with or without the only service pack released for it (SP1, because OSR 2 was not released as a service pack, only as an
"OEM
service release" for new computers), shipped only the even older CRTDLL.DLL (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL
had
to be installed through a redistributable (which was included with many applications including Microsoft Office, but it was not part of the operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows
version
numbers are not anywhere near monotonic ;-) ), MSVCRT is included out
of
the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today.
There's a variety of sites claiming to have stats on different Windows versions. They all show Windows 10 with the majority, but disagree on just how much older stuff still gets used. As one example though, this shows Windows 7 with 12 % and Windows 8.1 on 3 %. That 15% is too significant to declare that MSVCRT is deprecated yet.
https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/
FYI, UCRT can be installed on various Windows: https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-...
We should also look at the cost/benefit for Fedora to ship and maintain MSVCRT environments.
If it's merely for developers to check the build, one target is probably enough.
Release build should be tested on Windows. It is easy to build and test natively with msys2 nowadays, or build for other targets. Why not use that?
On Mon, Feb 07, 2022 at 01:38:17PM +0400, Marc-André Lureau wrote:
Hi
On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote:
Hi
On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
MSVCRT […] Works out of the box on every Microsoft Windows versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR
The original Windows 95, with or without the only service pack released for it (SP1, because OSR 2 was not released as a service pack, only as an
"OEM
service release" for new computers), shipped only the even older CRTDLL.DLL (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL
had
to be installed through a redistributable (which was included with many applications including Microsoft Office, but it was not part of the operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows
version
numbers are not anywhere near monotonic ;-) ), MSVCRT is included out
of
the box, UCRT is not. Is it really a good default to depend on a runtime library that is only included in Windows ≥ 10?
This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today.
There's a variety of sites claiming to have stats on different Windows versions. They all show Windows 10 with the majority, but disagree on just how much older stuff still gets used. As one example though, this shows Windows 7 with 12 % and Windows 8.1 on 3 %. That 15% is too significant to declare that MSVCRT is deprecated yet.
https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/
FYI, UCRT can be installed on various Windows: https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-...
Can be done automatically by the application's own MSI/NSIS installer ? Requiring the users to do that separately is not desirable.
We should also look at the cost/benefit for Fedora to ship and maintain MSVCRT environments.
Or we could look at the cost/benefit of adding UCRT to Fedora, since that's the change being proposed in this thread. In this thread
https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org/...
you're proposing that Fedora stop shipping any mingw packages at all, and just rely on MSys2 to do the packaging work. If that is the desired solution, is it actually a benefit to spend any effort adding -ucrt64 sub-RPMs to every mingw package in Fedora today ?
Release build should be tested on Windows. It is easy to build and test natively with msys2 nowadays, or build for other targets. Why not use that?
See my answers to this question elsewhere in this thread.
Regards, Daniel
Hi
On Mon, Feb 7, 2022 at 2:00 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Mon, Feb 07, 2022 at 01:38:17PM +0400, Marc-André Lureau wrote:
Hi
On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote:
Hi
On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
MSVCRT […] Works out of the box on every Microsoft Windows
versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95
OSR
The original Windows 95, with or without the only service pack
released
for it (SP1, because OSR 2 was not released as a service pack, only as
an
"OEM
service release" for new computers), shipped only the even older CRTDLL.DLL (which MinGW stopped supporting years ago) out of the box,
MSVCRT.DLL
had
to be installed through a redistributable (which was included with
many
applications including Microsoft Office, but it was not part of the operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows
version
numbers are not anywhere near monotonic ;-) ), MSVCRT is included
out
of
the box, UCRT is not. Is it really a good default to depend on a
runtime
library that is only included in Windows ≥ 10?
This proposal doesn't change the default. Although we can discuss
whether
deprecating msvcrt support in Fedora-MinGW would make sense today.
There's a variety of sites claiming to have stats on different Windows versions. They all show Windows 10 with the majority, but disagree on just how much older stuff still gets used. As one example though, this shows Windows 7 with 12 % and Windows 8.1 on 3 %. That 15% is too significant to declare that MSVCRT is deprecated yet.
https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/
FYI, UCRT can be installed on various Windows:
https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-...
Can be done automatically by the application's own MSI/NSIS installer ? Requiring the users to do that separately is not desirable.
Those are MSU, they can be installed with wusa.exe. From NSIS should be trivial. With WiX, MsuPackage (not supported by wixl atm) or CustomAction.
We should also look at the cost/benefit for Fedora to ship and maintain MSVCRT environments.
Or we could look at the cost/benefit of adding UCRT to Fedora, since that's the change being proposed in this thread. In this thread
https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org/...
you're proposing that Fedora stop shipping any mingw packages at all, and just rely on MSys2 to do the packaging work. If that is the desired solution, is it actually a benefit to spend any effort adding -ucrt64 sub-RPMs to every mingw package in Fedora today ?
If the msys2 solution works, then there isn't much benefit shipping mingw*-packages, except for what Sandro said, to sync the Fedora native and windows versions.
Marc-André Lureau wrote:
FYI, UCRT can be installed on various Windows: https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-...
Sure, it *can* be. But that doesn't mean I can rely on my end users to be able to do that. Currently I can ship a single 32-bit MSVCRT binary and be sure it'll work on any version of Windows that matters. It'll also work in Wine or ReactOS.
Release build should be tested on Windows. It is easy to build and test natively with msys2 nowadays, or build for other targets. Why not use that?
Because I don't consider Microsoft Windows to be a suitable development platform. I have Windows virtual machines for testing but they expire every 90 days. Indeed, one of my chores for today is to reinstall three Windows VMs that have expired. I don't want to then have to reinstall a development environment when I already have everything I need on Fedora.
Ron
Kevin Kofler via devel wrote:
Marc-André Lureau wrote:
Release build should be tested on Windows. It is easy to build and test natively with msys2 nowadays, or build for other targets. Why not use that?
Because I do not have a computer running Windows, nor a Windows license.
PS: Well, actually, I still have original CDs of Windows 95 and Windows Me lying around, but those are not going to be practical for modern-day development.
I switched to full-time Fedora after my Windows Me installation broke down, and I do not miss Windows at all.
Kevin Kofler
On Mon, Feb 7, 2022 at 11:20 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Marc-André Lureau wrote:
Release build should be tested on Windows. It is easy to build and test natively with msys2 nowadays, or build for other targets. Why not use that?
Because I do not have a computer running Windows, nor a Windows license.
For my hobbyist game development, I rely on the Fedora MinGW stack to be able to produce Windows builds for them. I do all my own development and work from Fedora Linux and I'd rather not change that.
If anything, our MinGW stack is an amazing selling point compared to other distributions, because we provide a usable framework to build applications for Windows.
(Sidebar, I wish the target would be renamed from mingw to windows, because it's kind of confusing when we don't even rely on a glibc-nt port...)
Neal Gompa wrote:
(Sidebar, I wish the target would be renamed from mingw to windows,
Well, in addition to the trademark concerns, that would also lose the distinction from Cygwin.
because it's kind of confusing when we don't even rely on a glibc-nt port...)
That would not really be *Minimalist* GNU for Windows anymore, would it? :-)
Kevin Kofler
Am 07.02.22 um 18:08 schrieb Neal Gompa:
If anything, our MinGW stack is an amazing selling point compared to other distributions, because we provide a usable framework to build applications for Windows.
I'd like to second this. I felt relieved once I found out that I could build a tiny in-house C application for Windows (using DBUS via glib + a proprietary 32 bit black box DLL) purely on Linux.
meson can do all the cross-compilation, mingw glib provides .pc files and everything works beautifully just like you would compile a Linux executable. Since I got this working a year ago all of our release builds were done on Windows. I completely wiped Visual Studio and there was no bug report related to compilation or the build process since. :-)
Felix
On Mon, 7 Feb 2022 at 17:10, Neal Gompa wrote:
On Mon, Feb 7, 2022 at 11:20 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Marc-André Lureau wrote:
Release build should be tested on Windows. It is easy to build and test natively with msys2 nowadays, or build for other targets. Why not use that?
Because I do not have a computer running Windows, nor a Windows license.
For my hobbyist game development, I rely on the Fedora MinGW stack to be able to produce Windows builds for them. I do all my own development and work from Fedora Linux and I'd rather not change that.
If anything, our MinGW stack is an amazing selling point compared to other distributions, because we provide a usable framework to build applications for Windows.
It really is great. GCC's C++17 std::filesystem code supports Windows, but is entirely developed on Fedora. I cross-compile using mingw-w64 and test using Wine. If I couldn't do that on Fedora, the Windows support simply wouldn't exist.
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
Since mingw-*.spec are very repetitive and cumbersome to modify (each mingw32, mingw64, ucrt package has to be defined manually, and this is tedious and error-prone), a custom MinGW/Fedora tool or solution will be proposed. In the meantime, packages can be modified to add manually the new target.
I think this is an important point. If this is to be done manually, the transition will take forever and will consume a lot of maintainer resources. I would very much encourage you do first develop macroification to make the new subpackages easy to add. And once that is done, do spec file munging semi-automatically, like it was done when we were renaming python2 subpackages. (This was similar, because we needed to add a new %package section and related sections.) Once the whole thing is ready, use a provenpackager to update and build all packages. In my exprience, it is also important to ask maintainers to *not* do manual conversions, because if you add automatization later on, manually converted packages end up being a bit different and in the end are more trouble than running the automatic converted over a few additional files.
If that'd be helpful, I can dig up the scripts for python2. I'd be happy to help with building scripts to do the conversion here, though I know almost nil about mingw.
Zbyszek
Hi
On Tue, Feb 8, 2022 at 12:45 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
Since mingw-*.spec are very repetitive and cumbersome to modify (each mingw32, mingw64, ucrt package has to be defined manually, and this is tedious and error-prone), a custom MinGW/Fedora tool or solution will be proposed. In the meantime, packages can be modified to add manually the new target.
I think this is an important point. If this is to be done manually, the transition will take forever and will consume a lot of maintainer resources. I would very much encourage you do first develop macroification to make the new subpackages easy to add. And once that is done, do spec file munging semi-automatically, like it was done when we were renaming python2 subpackages. (This was similar, because we needed to add a new %package section and related sections.) Once the whole thing is ready, use a provenpackager to update and build all packages. In my exprience, it is also important to ask maintainers to *not* do manual conversions, because if you add automatization later on, manually converted packages end up being a bit different and in the end are more trouble than running the automatic converted over a few additional files.
If that'd be helpful, I can dig up the scripts for python2. I'd be happy to help with building scripts to do the conversion here, though I know almost nil about mingw.
So far, what I built is a custom python/jinja script to generate the spec, here is the code and example with mingw-zlib: https://gitlab.com/-/snippets/2243878
Ideally, we would use built-in RPM template facilities, but that may take a while: https://github.com/rpm-software-management/rpm/issues/1472.
It will be hard to automate the translation from existing spec to a template form, but I can eventually look at it.
Adding ucrt64 packages is still optional, and can be done manually anyway. Templating is optional too, obviously.
Also I don't know what are Daniel Berrange plans to have native and cross packages built from the same spec. We might end up with a very different solution then.
On Tue, Feb 08, 2022 at 02:13:34PM +0400, Marc-André Lureau wrote:
Hi
On Tue, Feb 8, 2022 at 12:45 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
Since mingw-*.spec are very repetitive and cumbersome to modify (each mingw32, mingw64, ucrt package has to be defined manually, and this is tedious and error-prone), a custom MinGW/Fedora tool or solution will be proposed. In the meantime, packages can be modified to add manually the new target.
I think this is an important point. If this is to be done manually, the transition will take forever and will consume a lot of maintainer resources. I would very much encourage you do first develop macroification to make the new subpackages easy to add. And once that is done, do spec file munging semi-automatically, like it was done when we were renaming python2 subpackages. (This was similar, because we needed to add a new %package section and related sections.) Once the whole thing is ready, use a provenpackager to update and build all packages. In my exprience, it is also important to ask maintainers to *not* do manual conversions, because if you add automatization later on, manually converted packages end up being a bit different and in the end are more trouble than running the automatic converted over a few additional files.
If that'd be helpful, I can dig up the scripts for python2. I'd be happy to help with building scripts to do the conversion here, though I know almost nil about mingw.
So far, what I built is a custom python/jinja script to generate the spec, here is the code and example with mingw-zlib: https://gitlab.com/-/snippets/2243878
Ideally, we would use built-in RPM template facilities, but that may take a while: https://github.com/rpm-software-management/rpm/issues/1472.
It will be hard to automate the translation from existing spec to a template form, but I can eventually look at it.
Adding ucrt64 packages is still optional, and can be done manually anyway. Templating is optional too, obviously.
Also I don't know what are Daniel Berrange plans to have native and cross packages built from the same spec. We might end up with a very different solution then.
It was this thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Regards, Daniel
On Tue, Feb 08, 2022 at 10:19:35AM +0000, Daniel P. Berrangé wrote:
Also I don't know what are Daniel Berrange plans to have native and cross packages built from the same spec. We might end up with a very different solution then.
It was this thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
The reponses were in general very positive to this idea… In particular packagers who maintain both non-mingw and mingw versions of the same package would like to see unification. But the thread is from Match 2021… do you think we can make this happen soonish, at least opt-in?
Zbyszek
On Tue, Feb 08, 2022 at 02:13:34PM +0400, Marc-André Lureau wrote:
So far, what I built is a custom python/jinja script to generate the spec, here is the code and example with mingw-zlib: https://gitlab.com/-/snippets/2243878
Ideally, we would use built-in RPM template facilities, but that may take a while: https://github.com/rpm-software-management/rpm/issues/1472.
Yes, I think you need to assume that this will not happen soon. (If ever. I think that there are significant doubts whether this type of templating is desirable.)
It will be hard to automate the translation from existing spec to a template form, but I can eventually look at it.
Adding ucrt64 packages is still optional, and can be done manually anyway. Templating is optional too, obviously.
Hmm, but wouldn't the goal be to provide ucrt64 everywhere where there are existing mingw packages? If users are to transition to ucrt64, they would need to be able to assume that they can do that without regressions.
Zbyszek
On Tue, Feb 08, 2022 at 12:54:32PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 08, 2022 at 02:13:34PM +0400, Marc-André Lureau wrote:
So far, what I built is a custom python/jinja script to generate the spec, here is the code and example with mingw-zlib: https://gitlab.com/-/snippets/2243878
Ideally, we would use built-in RPM template facilities, but that may take a while: https://github.com/rpm-software-management/rpm/issues/1472.
Yes, I think you need to assume that this will not happen soon. (If ever. I think that there are significant doubts whether this type of templating is desirable.)
It will be hard to automate the translation from existing spec to a template form, but I can eventually look at it.
Adding ucrt64 packages is still optional, and can be done manually anyway. Templating is optional too, obviously.
Hmm, but wouldn't the goal be to provide ucrt64 everywhere where there are existing mingw packages? If users are to transition to ucrt64, they would need to be able to assume that they can do that without regressions.
Yes, if we're going to add ucrt64 support then I think the expectations a would be for it to be added in all packages, in a reasonably timely manner. Doing everything in 1 release is likely unrealistic, but at the same time it isn't nice to let it drag out over an indefinite number of releases.
As a historical reference, see when we added mingw64 support to the existing mingw32 packages:
https://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler
That was a bit more complex as it was actuallly swapping out the toolchain, and rebuilding all existing mingw32 packages with the new mingww64 toolchain, as well as then adding mingw64 sub-RPMs
The actual Fedora targetting Fedora 17 was simply to get the toolchain and basic runtime bootstrapped and into Fedora 17. The conversion of existing packages to add -mingw64 sub-RPM was not gated on Fedora 17, it was an asynchronous task. Most packages were converted via an out of tree testing repo ahead of the feature being propposed, to prove the viability of the work, so just needed to have pre-existing work merged.
IIRC, Fedora 17 introduced mingw64 toolchain and converted alot of packages, and pretty much everything remaining was finished converting in F18 cycle.
I think a feature page proposal is reasonable in suggesting the initial feature target is bootstrapping the base ucrt64 support and converting some common packages.
I'm not quite so convinced by punting conversion of everything else to "other developers", with no expectation of when this work is to be completed. I fear this means alot of conversion just won't get done in a timely manner.
Regards, Daniel
-
Ben Cotton -
Daniel P. Berrangé -
Felix Schwarz -
Jonathan Wakely -
Kevin Kofler -
Marc-André Lureau -
Michael Cronenworth -
Neal Gompa -
Richard W.M. Jones -
Ron Yorston -
Sandro Mani -
Tomasz Torcz -
Zbigniew Jędrzejewski-Szmek