Bug 2096010
| Summary: | Please consider shipping mingw{32,64}-gcc-c++ for non-x86_64 arches | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Orion Poplawski <orion> |
| Component: | mingw-gcc | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | tingting zheng <tzheng> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | CentOS Stream | CC: | ailan, bstinson, jwboyer, rjones, tzheng |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | mingw-gcc-12.0.1-11.2.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-15 11:23:46 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
(Attention jwb ..) Interestingly we do build them on all architectures already, but I guess we must filter them out at the release engineering stage. I have no particular objection to shipping them on all architectures, since it won't require any more maintenance work, and it makes all the arches similar which is generally useful. It'll also be easier than trying to build them again in EPEL, if that's even possible. Josh, what would we need to do here? Orion, can you help us understand the use here a bit? What packages need mingw{32,64}-gcc-c++ on e.g. s390x and ppc64le? It seems odd that one would be building a toolchain that targets Windows from those architectures.
I am no mingw export or particularly involved in mingw packaging, I'm just trying to get deps into EPEL9. I'm sure Richard knows much more than me.
Fedora seems to build mingw packages on all arches by default so it's easiest from a packaging standpoint to keep that in place. Now, while the mingw32/64-gcc packages are arch specific, the resulting mingw32/64- packages from libraries (and apps?) are built as "noarch" packages. Presumably this allows one to build Windows applications on a number of different host machines. I think mingw is more of a cross-build environment than a native build environment?
Now perhaps it would make more sense to only build the mingw libraries on a single architecture. If Fedora was interested in standardizing on a particular config in that way with helper macros that might be a way forward. But at the moment we're faced with something like:
%if 0%{?rhel} >= 9
%ifarch x86_64
%bcond_without mingw
%else
%bcond_with mingw
%endif
%else
%bcond_withtout mingw
%endif
and a bunch of:
%if %{with mingw}
%endif
conditionals sprinkled through combined native/mingw packages which is pretty ugly.
The packages are a mix of noarch and arch-ful. The noarch packages (eg mingw64-glib2-2.66.7-3.el9.noarch.rpm) contain Windows libraries. The arch-ful packages (eg mingw64-gcc-12.0.1-11.1.el9.x86_64.rpm) contain the cross-compiler components that you have to run to cross-compile your source code and link it to the Windows libraries to form a final .exe Anyway I was looking at what we actually ship across architectures on C9S, and it's an odd mixture. On x86_64 we ship everything: http://mirror.stream.centos.org/9-stream/CRB/x86_64/os/Packages/ On ppc64le we ship most bits of mingw* but miss out mingw*-gcc, and mingw*-glib2. On the other hand we do ship mingw*-binutils. This makes no sense to me at all: http://mirror.stream.centos.org/9-stream/CRB/ppc64le/os/Packages/ Note that all of these arch-ful packages are actually built in Koji, eg for mingw-gcc: https://kojihub.stream.rdu2.redhat.com/koji/buildinfo?buildID=18446 We just seem to be dropping random packages between Koji and the mirrors. I don't really understand why we miss out some packages but not others, even though we build everything. I agree that we should just ship everything the same on all architectures as much as possible. It makes everyone's lives easier. Making EPEL conditionalize spec files to deal with this is silly. Any progress/decisions here? It would be a great help with EPEL packaging and we're trying to move forward with more packages. Thanks. (In reply to Orion Poplawski from comment #8) > Any progress/decisions here? It would be a great help with EPEL packaging > and we're trying to move forward with more packages. Thanks. I don't mind having these packages shipped on all arches, but at the same time I have no idea how that could be done. Best to hope Red Hat release engineering team are able to do something. So contrary to my previous comment, rel-eng have actually supplied the method which I'll try to make work ... Tingting, could you look at QA ACK here? The only requirement is to check that the mingw-gcc* packages are being shipped on all architectures. There is no need to test that they work. Business justification: We should ship the same set of packages on all architectures to help EPEL, which is an important adjunct repository for RHEL users. (In reply to Richard W.M. Jones from comment #12) > Tingting, could you look at QA ACK here? The only requirement is to check > that the mingw-gcc* packages are being shipped on all architectures. > There is no need to test that they work. Done. https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/268 I'm not certain when this change will take effect, possibly after 9.1 is released or maybe sooner. (In reply to Richard W.M. Jones from comment #16) > https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/ > merge_requests/268 > > I'm not certain when this change will take effect, possibly after 9.1 is > released or maybe sooner. It should be reflected in a CentOS Stream compose in the next couple of weeks. Note to the reporter, if you look in the comps file: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/blob/main/comps-centos-stream-9.xml.in you'll see there are quite a few other packages that have the presumably unwanted arch="x86_64" attribute. If those packages are wrong you will need to file new bugs for each incorrect source package. Tested the bug with: http://download.eng.pek2.redhat.com//rhel-9/nightly/RHEL-9/RHEL-9.1.0-20220721.1 I can find mingw*-gcc packages in CRB compose for all arches. For mingw*-glib2 mentioned in comment 6, do we need it for all arches, now I can only find it under X86_64. This bug is only about mingw-gcc* packages. As noted in comment 19 if other mingw* packages have the same problem, new bugs must be filed by the reporter. I don't see any new bugs so far, so I assume that's not a problem. (In reply to Richard W.M. Jones from comment #22) > This bug is only about mingw-gcc* packages. As noted in comment 19 > if other mingw* packages have the same problem, new bugs must be > filed by the reporter. I don't see any new bugs so far, so I assume > that's not a problem. Thanks, mark the bug as Tested. Checked latest RHEL9.1 compose, mingw*-gcc packages have been added in CRB compose for all arches. Based on the comments, move the bug to VERIFIED. Thank you everyone. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Low: mingw-gcc security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:8415 |
Description of problem: In the process of building various Fedora mingw packages for EPEL9 we are discovering that mingw{32,64}-gcc-c++ is not available for non-x86_64 arches. This leads to the need for cumbersome conditionals in the spec files. Please consider shipping mingw{32,64}-gcc-c++ for non-x86_64 arches. Thank you. Version-Release number of selected component (if applicable): 11.2.1-3.el9