Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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/45994bf93bb4b030e3ab57c9b2e4e61e737d6d29
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-libvirt-glib.spec.in
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/f6cc2b6d756f8201c3119b34046a4da5bf85456a?branch=rawhide)
Thanks
Sandrô
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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/45994bf93bb4b030e3ab57c9b2e4e61e737d6d29
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-libvirt-glib.spec.in
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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Tue, Feb 08, 2022 at 10:19:35AM +, Daniel P. Berrangé wrote: > > Also I don't know what are Daniel Berrange plans to have native and cross > > packages built from the same spec. We might end up with a very different > > solution then. > > It was this thread: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FR5OEMAIROHKECQB2NGLMMXQGG7IQMHM/ 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 < > zbys...@in.waw.pl> wrote: > > > > https://fedoraproject.org/wiki/Changes/F37MingwUCRT > > > > > > Since mingw-*.spec are very repetitive and cumbersome to modify (each > > > mingw32, mingw64, ucrt package has to be defined manually, and this is > > > tedious and error-prone), a custom MinGW/Fedora tool or solution will > > > be proposed. In the meantime, packages can be modified to add manually > > > the new target. > > > > I think this is an important point. If this is to be done manually, > > the transition will take forever and will consume a lot of maintainer > > resources. I would very much encourage you do first develop macroification > > to make the new subpackages easy to add. And once that is done, do spec > > file munging semi-automatically, like it was done when we were renaming > > python2 subpackages. (This was similar, because we needed to add a new > > %package > > section and related sections.) Once the whole thing is ready, use a > > provenpackager > > to update and build all packages. In my exprience, it is also important to > > ask maintainers to *not* do manual conversions, because if you add > > automatization > > later on, manually converted packages end up being a bit different and in > > the end > > are more trouble than running the automatic converted over a few additional > > files. > > > > If that'd be helpful, I can dig up the scripts for python2. I'd be happy > > to help > > with building scripts to do the conversion here, though I know almost nil > > about > > mingw. > > > > So far, what I built is a custom python/jinja script to generate the spec, > here is the code and example with mingw-zlib: > https://gitlab.com/-/snippets/2243878 > > Ideally, we would use built-in RPM template facilities, but that may take a > while: https://github.com/rpm-software-management/rpm/issues/1472. > > It will be hard to automate the translation from existing spec to a > template form, but I can eventually look at it. > > Adding ucrt64 packages is still optional, and can be done manually anyway. > Templating is optional too, obviously. > > Also I don't know what are Daniel Berrange plans to have native and cross > packages built from the same spec. We might end up with a very different > solution then. It was this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FR5OEMAIROHKECQB2NGLMMXQGG7IQMHM/ 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Tue, Feb 8, 2022 at 12:45 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > > https://fedoraproject.org/wiki/Changes/F37MingwUCRT > > > > Since mingw-*.spec are very repetitive and cumbersome to modify (each > > mingw32, mingw64, ucrt package has to be defined manually, and this is > > tedious and error-prone), a custom MinGW/Fedora tool or solution will > > be proposed. In the meantime, packages can be modified to add manually > > the new target. > > I think this is an important point. If this is to be done manually, > the transition will take forever and will consume a lot of maintainer > resources. I would very much encourage you do first develop macroification > to make the new subpackages easy to add. And once that is done, do spec > file munging semi-automatically, like it was done when we were renaming > python2 subpackages. (This was similar, because we needed to add a new > %package > section and related sections.) Once the whole thing is ready, use a > provenpackager > to update and build all packages. In my exprience, it is also important to > ask maintainers to *not* do manual conversions, because if you add > automatization > later on, manually converted packages end up being a bit different and in > the end > are more trouble than running the automatic converted over a few additional > files. > > If that'd be helpful, I can dig up the scripts for python2. I'd be happy > to help > with building scripts to do the conversion here, though I know almost nil > about > mingw. > So far, what I built is a custom python/jinja script to generate the spec, here is the code and example with mingw-zlib: https://gitlab.com/-/snippets/2243878 Ideally, we would use built-in RPM template facilities, but that may take a while: https://github.com/rpm-software-management/rpm/issues/1472. It will be hard to automate the translation from existing spec to a template form, but I can eventually look at it. Adding ucrt64 packages is still optional, and can be done manually anyway. Templating is optional too, obviously. Also I don't know what are Daniel Berrange plans to have native and cross packages built from the same spec. We might end up with a very different solution then. -- Marc-André Lureau ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Mon, 7 Feb 2022 at 17:10, Neal Gompa wrote: > > On Mon, Feb 7, 2022 at 11:20 AM 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. > > > > 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
> 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Mon, Feb 7, 2022 at 11:20 AM 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. > 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Marc-André Lureau wrote: >FYI, UCRT can be installed on various Windows: >https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Mon, Feb 7, 2022 at 2:00 PM Daniel P. Berrangé 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é > > wrote: > > > > > On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > > > > Hi > > > > > > > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > > > > devel@lists.fedoraproject.org> wrote: > > > > > > > > > For the record: > > > > > > > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > > > > MSVCRT […] Works out of the box on every Microsoft Windows > versions. > > > > > > > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 > OSR > > > 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-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c > > 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/mi...@lists.fedoraproject.org/message/6G2EAKYSNWMLDBWZ2BYQS3BEIRKJ2EEG/ > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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é > > 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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é > wrote: > > > On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > > > Hi > > > > > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > > > devel@lists.fedoraproject.org> wrote: > > > > > > > For the record: > > > > > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > > > MSVCRT […] Works out of the box on every Microsoft Windows versions. > > > > > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR > > 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-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c 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/mi...@lists.fedoraproject.org/message/6G2EAKYSNWMLDBWZ2BYQS3BEIRKJ2EEG/ 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On 07.02.22 10:29, Marc-André Lureau wrote: Hi On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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é > 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Mon, Feb 7, 2022 at 1:16 PM Daniel P. Berrangé wrote: > On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > > devel@lists.fedoraproject.org> wrote: > > > > > For the record: > > > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > > MSVCRT […] Works out of the box on every Microsoft Windows versions. > > > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR > 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-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > Hi > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > > > For the record: > > > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > > MSVCRT […] Works out of the box on every Microsoft Windows versions. > > > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. > > The original Windows 95, with or without the only service pack released > > for > > it (SP1, because OSR 2 was not released as a service pack, only as an "OEM > > service release" for new computers), shipped only the even older > > CRTDLL.DLL > > (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had > > to > > be installed through a redistributable (which was included with many > > applications including Microsoft Office, but it was not part of the > > operating system). > > > > But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version > > numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of > > the > > box, UCRT is not. Is it really a good default to depend on a runtime > > library > > that is only included in Windows ≥ 10? > > > > This proposal doesn't change the default. Although we can discuss whether > deprecating msvcrt support in Fedora-MinGW would make sense today. There's a variety of sites claiming to have stats on different Windows versions. They all show Windows 10 with the majority, but disagree on just how much older stuff still gets used. As one example though, this shows Windows 7 with 12 % and Windows 8.1 on 3 %. That 15% is too significant to declare that MSVCRT is deprecated yet. https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/ > Fwiw, given that the primary use case for a cross-toolchain is for > developer needs, I think it is reasonable to have only UCRT target in the > future. At some point off in the future maybe, but we would need to see the stats for older Windows 7/8 releases drop significantly lower than they are today. > > Projects releasing for Windows should probably natively build and test > their releases with Msys2, and they can do so for msvcrt targets. Testing yes, but building no. I do all Windows builds using Fedora cross compilation, using pristine mock chroots. The idea of building under Msys2 on a Windows machine I now have to maintain in a pristine condition, is not at all appealing. I don't want to have to figure out a different way to build that's equivalent to what mock offers me. It is much more appealing to have a single machine from which I can do both Linux and Windows builds using the same basic infra for both Regards, Daniel -- |: 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Sat, Feb 5, 2022 at 5:54 AM Richard W.M. Jones 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Sat, Feb 5, 2022 at 2:44 AM Richard W.M. Jones wrote: > On Fri, Feb 04, 2022 at 05:20:31PM +0400, Marc-André Lureau wrote: > > Projects releasing for Windows should probably natively build and test > their > > releases with Msys2, and they can do so for msvcrt targets. > > This isn't a very useful suggestion. We build using mingw precisely > to avoid touching Windows at all. > Even freedesktop offers Windows CI instances where you can build natively. I have honest doubts about projects doing releases for Windows without ever running it. > I'm a little confused about the thread though. If we use mingw32-* > after this change, does it still use msvcrt? > There is no change on the existing mingw32 and mingw64 targets. Did you read the proposal? :) > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Marc-André Lureau ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Fri, Feb 4, 2022 at 8:21 AM Marc-André Lureau wrote: > > Hi > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel > 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Hi On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > For the record: > > https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > > MSVCRT […] Works out of the box on every Microsoft Windows versions. > > This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. > The original Windows 95, with or without the only service pack released > for > it (SP1, because OSR 2 was not released as a service pack, only as an "OEM > service release" for new computers), shipped only the even older > CRTDLL.DLL > (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had > to > be installed through a redistributable (which was included with many > applications including Microsoft Office, but it was not part of the > operating system). > > But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version > numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of > the > box, UCRT is not. Is it really a good default to depend on a runtime > library > that is only included in Windows ≥ 10? > This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today. Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future. Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets. But there is at least one user that may legitimately want to keep a msvcrt 32bit target: mingw-wine-gecko. -- Marc-André Lureau ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
Tomasz Torcz 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 to...@pipebreaker.plwagon filled with backup tapes.” — Jim Gray ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)
On Sat, Jan 29, 2022 at 12:32 PM Ben Cotton 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.lur...@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/mi...@lists.fedoraproject.org/thread/JCJCOYRVD2J5UIK5TJXHNVDHNEBZWL43/ > UCRT plans on mi...@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 == > > > $ x86_64-w64-mingw32ucrt-gcc test.c > > $ /usr/bin/mingw-objdump -p a.exe | grep DLL > vma:HintTime 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 > > > > == 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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.lur...@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/mi...@lists.fedoraproject.org/thread/JCJCOYRVD2J5UIK5TJXHNVDHNEBZWL43/ UCRT plans on mi...@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 == $ x86_64-w64-mingw32ucrt-gcc test.c $ /usr/bin/mingw-objdump -p a.exe | grep DLL vma:HintTime 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 == 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 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change: MinGW UCRT target (Self-Contained Change proposal)
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.lur...@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/mi...@lists.fedoraproject.org/thread/JCJCOYRVD2J5UIK5TJXHNVDHNEBZWL43/ UCRT plans on mi...@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 == $ x86_64-w64-mingw32ucrt-gcc test.c $ /usr/bin/mingw-objdump -p a.exe | grep DLL vma:HintTime 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 == 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
