F37 Change: MinGW UCRT target (Self-Contained Change proposal)

[Ben Cotton]

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(a)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/[e-mail].o...
UCRT plans on  mingw(a)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.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Neal Gompa]

On Sat, Jan 29, 2022 at 12:32 PM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)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/[e-mail].o...
>  UCRT plans on  mingw(a)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!

[Kevin Kofler]

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

[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

[Tomasz Torcz]

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               “Never underestimate the bandwidth of a station
tomek(a)pipebreaker.pl        wagon filled with backup tapes.”  — Jim Gray

[Ron Yorston]

Tomasz Torcz <tomek(a)pipebreaker.pl&gt; 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

[Marc-André Lureau]

Hi

On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel <
devel(a)lists.fedoraproject.org&gt; 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.

-- 
Marc-André Lureau

[Neal Gompa]

On Fri, Feb 4, 2022 at 8:21 AM Marc-André Lureau
<marcandre.lureau(a)gmail.com&gt; wrote:
>  Hi
>
>  On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel
> <devel(a)lists.fedoraproject.org&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Michael Cronenworth]

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.

[1] https://github.com/msys2/MINGW-packages/issues/6901

[Richard W.M. Jones]

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.

-- 
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/

[Marc-André Lureau]

Hi

On Sat, Feb 5, 2022 at 2:44 AM Richard W.M. Jones <rjones(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
Marc-André Lureau

[Richard W.M. Jones]

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(a)redhat.com&gt; 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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Kevin Kofler]

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. ;-)

        Kevin Kofler

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Neal Gompa]

On Sat, Feb 5, 2022 at 5:54 AM Richard W.M. Jones <rjones(a)redhat.com&gt; 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...



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Richard W.M. Jones]

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(a)redhat.com&gt; 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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Felix Schwarz]

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

[Kevin Kofler]

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

[Daniel P. Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Marc-André Lureau]

Hi

On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé <berrange(a)redhat.com&gt;
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)


-- 
Marc-André Lureau

[Daniel P. Berrangé]

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(a)redhat.com&gt;
>  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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Sandro Mani]

On 07.02.22 10:29, Marc-André Lureau wrote:
>  Hi
>
>  On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé 
>  <berrange(a)redhat.com&gt; 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

[Daniel P. Berrangé]

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(a)redhat.com&gt;
>  > 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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Sandro Mani]

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

[Sandro Mani]

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

[Daniel P. Berrangé]

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/45994bf93bb4b030e3ab57c...

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

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Sandro Mani]

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/45994bf93bb4b030e3ab57c...
>
>  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-li...
>
>  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/f6cc2b6d756f8201c31...)

Thanks
Sandrô

[Daniel P. Berrangé]

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(a)lists.fedoraproject.org&gt; 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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Marc-André Lureau]

Hi

On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé <berrange(a)redhat.com&gt;
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(a)lists.fedoraproject.org&gt; 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/ 

FYI, UCRT can be installed on various Windows:
https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-...

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?


-- 
Marc-André Lureau

[Daniel P. Berrangé]

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(a)redhat.com&gt;
>  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(a)lists.fedoraproject.org&gt; 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/
>  
>  
>  FYI, UCRT can be installed on various Windows:
>
> https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-...
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/[e-mail].o...

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Marc-André Lureau]

Hi

On Mon, Feb 7, 2022 at 2:00 PM Daniel P. Berrangé <berrange(a)redhat.com&gt;
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(a)redhat.com&gt;
>  > 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(a)lists.fedoraproject.org&gt; 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/
>  >
>  >
>  > FYI, UCRT can be installed on various Windows:
>  >
>
> https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-...
>
>  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/[e-mail].o...
>
>  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

[Ron Yorston]

Marc-André Lureau wrote:
> FYI, UCRT can be installed on various Windows:
> https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-...
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]

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.

        Kevin Kofler

[Kevin Kofler]

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

[Neal Gompa]

On Mon, Feb 7, 2022 at 11:20 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; 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...)


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

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

[Felix Schwarz]

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

[Jonathan Wakely]

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(a)lists.fedoraproject.org&gt; 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.

[Zbigniew Jędrzejewski-Szmek]

>  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

[Marc-André Lureau]

Hi

On Tue, Feb 8, 2022 at 12:45 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl&gt; 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.

-- 
Marc-André Lureau

[Daniel P. Berrangé]

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(a)in.waw.pl&gt; 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/[e-mail].o...


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Zbigniew Jędrzejewski-Szmek]

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/[e-mail].o...
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

[Zbigniew Jędrzejewski-Szmek]

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

[Daniel P. Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|