7:32 a.m.
Hi Sandro & list,
UCRT seems to be the recommended C runtime for a bit more than 2 years
now. It solves issues with utf8, C standard, interop with MSVC etc.
Do we have plans to start adding that target? Apparently we would need
a new target prefix ucrt64-, and compile crt/headers
--with-default-msvcrt=ucrt64 etc. I could eventually give it a shot.
Regarding long-term plans, should we plan to drop 32 bit targets? it's
a niche nowadays.
thanks
8:03 a.m.
Hi Marc
On my part, feel free to give it a shot. To be honest personally I don't
really know enough about UCRT to judge the consequences.
Regarding mingw32, I think the discussion came up some time ago when I
proposed changing the mingw32 exception model to be able to build rust.
If memory serves me right, there were still some use-cases for mingw32,
perhaps mingw-gecko/wine? Michael can you add more maybe?
Thanks
Sandro
On 14.01.22 14:32, Marc-André Lureau wrote:
> Hi Sandro & list,
>
> UCRT seems to be the recommended C runtime for a bit more than 2 years
> now. It solves issues with utf8, C standard, interop with MSVC etc.
>
> Do we have plans to start adding that target? Apparently we would need
> a new target prefix ucrt64-, and compile crt/headers
> --with-default-msvcrt=ucrt64 etc. I could eventually give it a shot.
>
> Regarding long-term plans, should we plan to drop 32 bit targets? it's
> a niche nowadays.
>
> thanks
>
6:36 a.m.
Hi Sandro & all
On Fri, Jan 14, 2022 at 6:03 PM Sandro Mani <manisandro(a)gmail.com> wrote:
Hi Marc
On my part, feel free to give it a shot. To be honest personally I don't
really know enough about UCRT to judge the consequences.
I managed to bootstrap a ucrt toolchain on fedora:
$ 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
$ wine ./a.exe
002c:fixme:winediag:LdrInitializeThunk wine-staging 7.0-rc4 is a
testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact
version when filing bug reports on winehq.org.
hello
The common tool / package prefix I picked is ucrt64- (copy/replace of mingw64-).
I had to pick a target triple for sys-root and binary prefix. My
initial idea was x86_64-w64-ucrt. Unfortunatly, this doesn't pass
config.sub checks, which has a fixed set of OS patterns. So I picked
x86_64-w64-mingw32ucrt. Does that sound reasonable? Given that
-lmingw32 is still used, I think that makes sense... Who should we ask
for opinions, or if we are doing something wrong here?
This is the order of package build & install I followed:
- filesystem
- binutils
- headers + threads
- gcc bootstrap
- crt
- headers - threads (had to tweak temporarily Require: winpthread here..)
- winpthreads (seems necessary for gcc libs nowadays), with ssp flags disabled
- gcc
- winpthreads
- gcc gomp=1
The forks:
https://src.fedoraproject.org/forks/elmarco/rpms/mingw-filesystem.git
ucrt branch
https://src.fedoraproject.org/forks/elmarco/rpms/mingw-bintuils.git ucrt branch
https://src.fedoraproject.org/forks/elmarco/rpms/mingw-headers.git ucrt branch
https://src.fedoraproject.org/forks/elmarco/rpms/mingw-gcc.git ucrt branch
https://src.fedoraproject.org/forks/elmarco/rpms/mingw-winpthreads.git
ucrt branch
Any comments? How to proceed next?
Thanks!
Regarding mingw32, I think the discussion came up some time ago when
I
proposed changing the mingw32 exception model to be able to build rust.
If memory serves me right, there were still some use-cases for mingw32,
perhaps mingw-gecko/wine? Michael can you add more maybe?
Thanks
Sandro
On 14.01.22 14:32, Marc-André Lureau wrote:
> Hi Sandro & list,
>
> UCRT seems to be the recommended C runtime for a bit more than 2 years
> now. It solves issues with utf8, C standard, interop with MSVC etc.
>
> Do we have plans to start adding that target? Apparently we would need
> a new target prefix ucrt64-, and compile crt/headers
> --with-default-msvcrt=ucrt64 etc. I could eventually give it a shot.
>
> Regarding long-term plans, should we plan to drop 32 bit targets? it's
> a niche nowadays.
>
> thanks
>
9 a.m.
Hi
On Sat, Jan 15, 2022 at 4:36 PM Marc-André Lureau
<marcandre.lureau(a)redhat.com> wrote:
Any comments? How to proceed next?
I wrote a Fedora change proposal:
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
Regarding update of the mingw-* libraries packages (to add or remove
targets in the future), I have looked at various options to
"templatize" the spec, to avoid having to add a third repetition of
package definition. I think we can't really do it with the current RPM
macro system (there are discussions in
https://github.com/rpm-software-management/rpm/issues/1472 for
example). Not only lua isn't the most convenient programming language
for the task, but I don't see how you could give a multi-line string
to a lua macro in a sane way.
What I would propose so far is to provide a mingw-tmpl program that
will generate the .spec from a .tmpl.spec. Such template is optional
and should be added to dist-git. Here is a gist
https://gitlab.com/-/snippets/2243878 to give you an idea of what it
looks like when templating mingw-zlib. The resulting .spec file is to
be committed and packaged as usual.
Any feedback appreciated!
Thanks
1:02 p.m.
Thanks Marc
Just for curiosity, as you see it, does it make sense to keep both mingw
and ucrt moving forward?
Sandro
On 28.01.22 16:00, Marc-André Lureau wrote:
> Hi
>
> On Sat, Jan 15, 2022 at 4:36 PM Marc-André Lureau
> <marcandre.lureau(a)redhat.com> wrote:
>> Any comments? How to proceed next?
> I wrote a Fedora change proposal:
> https://fedoraproject.org/wiki/Changes/F37MingwUCRT
>
> Regarding update of the mingw-* libraries packages (to add or remove
> targets in the future), I have looked at various options to
> "templatize" the spec, to avoid having to add a third repetition of
> package definition. I think we can't really do it with the current RPM
> macro system (there are discussions in
> https://github.com/rpm-software-management/rpm/issues/1472 for
> example). Not only lua isn't the most convenient programming language
> for the task, but I don't see how you could give a multi-line string
> to a lua macro in a sane way.
>
> What I would propose so far is to provide a mingw-tmpl program that
> will generate the .spec from a .tmpl.spec. Such template is optional
> and should be added to dist-git. Here is a gist
> https://gitlab.com/-/snippets/2243878 to give you an idea of what it
> looks like when templating mingw-zlib. The resulting .spec file is to
> be committed and packaged as usual.
>
> Any feedback appreciated!
> Thanks
>
2:09 p.m.
Hi Sandro
On Fri, Jan 28, 2022 at 11:02 PM Sandro Mani <manisandro(a)gmail.com> wrote:
Thanks Marc
Just for curiosity, as you see it, does it make sense to keep both mingw
and ucrt moving forward?
Interesting question, it really depends on our users I imagine.
Since Windows recommends ucrt since Windows 10 (2015) and you can ship
UCRT for earlier versions up to Vista, there are very few reasons you
would want to keep msvcrt. Notably, wine may need msvcrt binaries.
However, if this is the only case, we probably don't want to keep
maintaining and distributing all the msvcrt binaries with Fedora.
My recommendation going forward (past f37 and ucrt toolchain
introduction probably, unless we all agree?) would be to remove
mingw32/64 libraries, but keep the various toolchains. This way, users
who still want to target msvcrt can rebuild their dependencies
themself relatively easily.
Sometime I even think more radically, and think that Fedora should
stop maintaining & distributing all the mingw libraries. Instead, work
with the msys2 project, to have a common place to maintain those. I am
not sure what shape this would take, but I am sure this could be very
fruitful, especially if other distros take the same approach
(debian/ubuntu/arch etc).
mingw* msvcrt targets
2:27 p.m.
Interesting question, it really depends on our users I imagine.
Since Windows recommends ucrt since Windows 10 (2015) and you can ship
UCRT for earlier versions up to Vista, there are very few reasons you
would want to keep msvcrt. Notably, wine may need msvcrt binaries.
However, if this is the only case, we probably don't want to keep
maintaining and distributing all the msvcrt binaries with Fedora.
My recommendation going forward (past f37 and ucrt toolchain
introduction probably, unless we all agree?) would be to remove
mingw32/64 libraries, but keep the various toolchains. This way, users
who still want to target msvcrt can rebuild their dependencies
themself relatively easily.
This is what I was kinda also thinking about. The one thing that scares
me TBH is having to go through rename-rereview of all mingw -> ucrt
packages. I wonder if one could handle it like
- ask FESCO to rename without re-rereview all mingw32/64-* packages to
win32/64-* (or whatever generic windows prefix), leaving the runtime out
of the package name
- when the time comes, change the runtime and just recompile the entire
mingw/win package set
So not even ever offering mingw and ucrt side-by-side, except perhaps
for the selected core toolchain packages to allow users to build their
own packages if they wish
Sometime I even think more radically, and think that Fedora should
stop maintaining & distributing all the mingw libraries. Instead, work
with the msys2 project, to have a common place to maintain those. I am
not sure what shape this would take, but I am sure this could be very
fruitful, especially if other distros take the same approach
(debian/ubuntu/arch etc).
I guess this would add the challange of keeping the packages in sync
with the corresponding native version (which is already quite a
challenge inside the distro actually).
2:50 p.m.
Hi
On Sat, Jan 29, 2022 at 12:27 AM Sandro Mani <manisandro(a)gmail.com> wrote:
> Interesting question, it really depends on our users I imagine.
>
> Since Windows recommends ucrt since Windows 10 (2015) and you can ship
> UCRT for earlier versions up to Vista, there are very few reasons you
> would want to keep msvcrt. Notably, wine may need msvcrt binaries.
> However, if this is the only case, we probably don't want to keep
> maintaining and distributing all the msvcrt binaries with Fedora.
>
> My recommendation going forward (past f37 and ucrt toolchain
> introduction probably, unless we all agree?) would be to remove
> mingw32/64 libraries, but keep the various toolchains. This way, users
> who still want to target msvcrt can rebuild their dependencies
> themself relatively easily.
This is what I was kinda also thinking about. The one thing that scares
me TBH is having to go through rename-rereview of all mingw -> ucrt
packages. I wonder if one could handle it like
Why renaming? what I propose is to add ucrt64-* libraries.
For example, we have mingw32-zlib & mingw64-zlib today. We would have
to add a third ucrt64-zlib.
It's tedious, but we don't have to do it all in one go, we can add it over time.
And with the simple template system I propose (until RPM provides
something) it is easier to adapt, it avoids having to repeat things.
- ask FESCO to rename without re-rereview all mingw32/64-* packages to
win32/64-* (or whatever generic windows prefix), leaving the runtime out
of the package name
- when the time comes, change the runtime and just recompile the entire
mingw/win package set
That won't work. One reason you need a transition period is also
because ucrt may introduce regressions in your package that you may
have to work on.. I have fixed a few ucrt-related issues in glib
(among others https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2449)
So not even ever offering mingw and ucrt side-by-side, except perhaps
for the selected core toolchain packages to allow users to build their
own packages if they wish
>
> Sometime I even think more radically, and think that Fedora should
> stop maintaining & distributing all the mingw libraries. Instead, work
> with the msys2 project, to have a common place to maintain those. I am
> not sure what shape this would take, but I am sure this could be very
> fruitful, especially if other distros take the same approach
> (debian/ubuntu/arch etc).
I guess this would add the challange of keeping the packages in sync
with the corresponding native version (which is already quite a
challenge inside the distro actually).
Fedora would no longer ship any library or windows binaries (almost),
only the cross toolchain.
You would simply run "msys2-pacman -S foopkg" and get either the same
package distributed for Windows installed somehow on your distro
(perhaps even under $HOME), or a side msys2 project could cross-build
them package for your target linux distro (if that's necessary, but I
think we could eventually get the same windows packages). For the vast
majority of packages, that approach should work.
The other approach is to simply vendor and cross-build your
dependencies with your project (like meson wrap, rust etc are doing).
The required bits are only the cross-toolchains then.
3:10 p.m.
On 28.01.22 21:50, Marc-André Lureau wrote:
Hi
On Sat, Jan 29, 2022 at 12:27 AM Sandro Mani <manisandro(a)gmail.com> wrote:
>
>> Interesting question, it really depends on our users I imagine.
>>
>> Since Windows recommends ucrt since Windows 10 (2015) and you can ship
>> UCRT for earlier versions up to Vista, there are very few reasons you
>> would want to keep msvcrt. Notably, wine may need msvcrt binaries.
>> However, if this is the only case, we probably don't want to keep
>> maintaining and distributing all the msvcrt binaries with Fedora.
>>
>> My recommendation going forward (past f37 and ucrt toolchain
>> introduction probably, unless we all agree?) would be to remove
>> mingw32/64 libraries, but keep the various toolchains. This way, users
>> who still want to target msvcrt can rebuild their dependencies
>> themself relatively easily.
> This is what I was kinda also thinking about. The one thing that scares
> me TBH is having to go through rename-rereview of all mingw -> ucrt
> packages. I wonder if one could handle it like
Why renaming? what I propose is to add ucrt64-* libraries.
For example, we have mingw32-zlib & mingw64-zlib today. We would have
to add a third ucrt64-zlib.
It's tedious, but we don't have to do it all in one go, we can add it over time.
And with the simple template system I propose (until RPM provides
something) it is easier to adapt, it avoids having to repeat things.
Wait I think I
got confused by the environments overview in [1], which I
read as ucrt being a separate thing than mingw, but it's just mingw with
the different runtime right? So to be precise, the one package should be
called say mingw64-msvc-zlib while the other mingw64-ucrt-zlib?
> - ask FESCO to rename without re-rereview all mingw32/64-*
packages to
> win32/64-* (or whatever generic windows prefix), leaving the runtime out
> of the package name
> - when the time comes, change the runtime and just recompile the entire
> mingw/win package set
That won't work. One reason you need a transition period is also
because ucrt may introduce regressions in your package that you may
have to work on.. I have fixed a few ucrt-related issues in glib
(among others https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2449)
Yes
indeed
> I guess this would add the challange of keeping the packages in
sync
> with the corresponding native version (which is already quite a
> challenge inside the distro actually).
Fedora would no longer ship any library or windows binaries (almost),
only the cross toolchain.
You would simply run "msys2-pacman -S foopkg" and get either the same
package distributed for Windows installed somehow on your distro
(perhaps even under $HOME), or a side msys2 project could cross-build
them package for your target linux distro (if that's necessary, but I
think we could eventually get the same windows packages). For the vast
majority of packages, that approach should work.
The other approach is to simply vendor and cross-build your
dependencies with your project (like meson wrap, rust etc are doing).
The required bits are only the cross-toolchains then.
So what was on my mind here
is that one of the attractiveness of the
current mingw environment is that (for a large part) you can develop the
application on your host system, and then cross-compile the builds for
windows, having a high confidence that the cross-compiled application
will have the same library versions as the ones you developed and tested
with natively. And having them pre-packaged clearly is a huge time-saver.
[1] https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt
3:35 p.m.
Hi
On Sat, Jan 29, 2022 at 1:10 AM Sandro Mani <manisandro(a)gmail.com> wrote:
On 28.01.22 21:50, Marc-André Lureau wrote:
> Hi
>
> On Sat, Jan 29, 2022 at 12:27 AM Sandro Mani <manisandro(a)gmail.com> wrote:
>>
>>> Interesting question, it really depends on our users I imagine.
>>>
>>> Since Windows recommends ucrt since Windows 10 (2015) and you can ship
>>> UCRT for earlier versions up to Vista, there are very few reasons you
>>> would want to keep msvcrt. Notably, wine may need msvcrt binaries.
>>> However, if this is the only case, we probably don't want to keep
>>> maintaining and distributing all the msvcrt binaries with Fedora.
>>>
>>> My recommendation going forward (past f37 and ucrt toolchain
>>> introduction probably, unless we all agree?) would be to remove
>>> mingw32/64 libraries, but keep the various toolchains. This way, users
>>> who still want to target msvcrt can rebuild their dependencies
>>> themself relatively easily.
>> This is what I was kinda also thinking about. The one thing that scares
>> me TBH is having to go through rename-rereview of all mingw -> ucrt
>> packages. I wonder if one could handle it like
> Why renaming? what I propose is to add ucrt64-* libraries.
>
> For example, we have mingw32-zlib & mingw64-zlib today. We would have
> to add a third ucrt64-zlib.
>
> It's tedious, but we don't have to do it all in one go, we can add it over
time.
>
> And with the simple template system I propose (until RPM provides
> something) it is easier to adapt, it avoids having to repeat things.
Wait I think I got confused by the environments overview in [1], which I
read as ucrt being a separate thing than mingw, but it's just mingw with
the different runtime right? So to be precise, the one package should be
called say mingw64-msvc-zlib while the other mingw64-ucrt-zlib?
Yes, it's mingw with a different target runtime.
Until ucrt, the target was only x86/x86-64 msvcrt, so mingw32/mingw64
prefix was used. I propose to add the ucrt64 prefix for the MinGW
UCRT64 x86-64 Fedora packages. To be pedantic, we should use something
like "mingw-w64-ucrt-x86_64" as package prefix I guess. ucrt64 is a
reasonable short form. That's also what msys2 picked for their
environment (MSYSTEM) and prefix (/ucrt64)
So it's not about renaming mingw64-zlib to mingw64-msvc-zlib, and
introducing mingw64-ucrt-zlib. It's only about adding ucrt64-zlib
(progressively, package by package as needed, over time)
>> - ask FESCO to rename without re-rereview all mingw32/64-*
packages to
>> win32/64-* (or whatever generic windows prefix), leaving the runtime out
>> of the package name
>> - when the time comes, change the runtime and just recompile the entire
>> mingw/win package set
> That won't work. One reason you need a transition period is also
> because ucrt may introduce regressions in your package that you may
> have to work on.. I have fixed a few ucrt-related issues in glib
> (among others https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2449)
Yes indeed
>> I guess this would add the challange of keeping the packages in sync
>> with the corresponding native version (which is already quite a
>> challenge inside the distro actually).
> Fedora would no longer ship any library or windows binaries (almost),
> only the cross toolchain.
>
> You would simply run "msys2-pacman -S foopkg" and get either the same
> package distributed for Windows installed somehow on your distro
> (perhaps even under $HOME), or a side msys2 project could cross-build
> them package for your target linux distro (if that's necessary, but I
> think we could eventually get the same windows packages). For the vast
> majority of packages, that approach should work.
>
> The other approach is to simply vendor and cross-build your
> dependencies with your project (like meson wrap, rust etc are doing).
>
> The required bits are only the cross-toolchains then.
So what was on my mind here is that one of the attractiveness of the
current mingw environment is that (for a large part) you can develop the
application on your host system, and then cross-compile the builds for
windows, having a high confidence that the cross-compiled application
will have the same library versions as the ones you developed and tested
with natively. And having them pre-packaged clearly is a huge time-saver.
That's a reasonable model. But how many Windows projects out there are
tight to the Fedora release lifecycle?
A serious Windows project that needs mingw is probably built and
tested on Windows, probably using msys2 or with a custom solution.
MinGW cross-compilation on Fedora is mostly for Linux developer
convenience, and other more marginal requirements.
3:46 p.m.
On 28.01.22 22:35, Marc-André Lureau wrote:
Yes, it's mingw with a different target runtime.
Until ucrt, the target was only x86/x86-64 msvcrt, so mingw32/mingw64
prefix was used. I propose to add the ucrt64 prefix for the MinGW
UCRT64 x86-64 Fedora packages. To be pedantic, we should use something
like "mingw-w64-ucrt-x86_64" as package prefix I guess. ucrt64 is a
reasonable short form. That's also what msys2 picked for their
environment (MSYSTEM) and prefix (/ucrt64)
So it's not about renaming mingw64-zlib to mingw64-msvc-zlib, and
introducing mingw64-ucrt-zlib. It's only about adding ucrt64-zlib
(progressively, package by package as needed, over time)
Ok understood.
> So what was on my mind here is that one of the attractiveness of
the
> current mingw environment is that (for a large part) you can develop the
> application on your host system, and then cross-compile the builds for
> windows, having a high confidence that the cross-compiled application
> will have the same library versions as the ones you developed and tested
> with natively. And having them pre-packaged clearly is a huge time-saver.
That's a reasonable model. But how many Windows projects out there are
tight to the Fedora release lifecycle?
A serious Windows project that needs mingw is probably built and
tested on Windows, probably using msys2 or with a custom solution.
MinGW cross-compilation on Fedora is mostly for Linux developer
convenience, and other more marginal requirements.
Would be nice to have some more
opinions of this. The reason why I'm
actually heavily involved in Fedora mingw packaging is because I do just
that - develop the applications on Linux and, in addition to the native
build, cross-compiled them for Windows, without needing any Windows
development environment. Windows testing is obviously still needed, but
for 99% of the cases, the issues found apply to both the native and the
cross-compiled binaries. So it is actually a huge time-saver.
816
days inactive
831
days old
11 comments
3 participants
participants (3)
-
Marc-André Lureau -
Michael Cronenworth -
Sandro Mani