Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
mingw-crt failed to build from source in Red Hat Enterprise Linux 9 CentOS Stream
https://kojihub.stream.rdu2.redhat.com//koji/taskinfo?taskID=247569
For details on the mass rebuild see:
Please fix mingw-crt at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it.
Comment 2Richard W.M. Jones
2021-04-26 13:42:02 UTC
mingw-* packages in RHEL 9 (not 8) are mine.
Comment 3Richard W.M. Jones
2021-04-26 15:05:29 UTC
This is actually a bug in mingw-binutils. The 'ar' tool crashes:
(gdb) bt
#0 __GI___fileno (fp=0x0) at fileno.c:35
#1 0x0000000000482e81 in ar_save () at ../../binutils/arsup.c:358
#2 yyparse.isra.0 ()
at /usr/src/debug/mingw-binutils-2.34-8.el9.x86_64/build_win32/binutils/arparse.y:131
#3 0x0000000000403cdb in mri_emul () at ../../binutils/ar.c:179
#4 main (argc=<optimized out>, argv=<optimized out>)
at ../../binutils/ar.c:778
Comment 4Richard W.M. Jones
2021-04-26 15:36:04 UTC
This is caused by the following downstream patch that we added for a CVE:
Subject: [PATCH] binutils: Make smart_rename safe too
Actually it's not even used in Fedora mingw-binutils. Since RHEL 9 binutils
has moved to 2.35 (vs mingw-binutils 2.34) I am going to synchronize this
with binutils
Comment 5Richard W.M. Jones
2021-04-26 15:38:37 UTC
Actually no the bogus patch is also present in RHEL 9 binutils
(binutils-CVE-2021-20197.patch). I don't think we can fix this
for mingw-binutils until this patch can be fixed.
Created attachment 1775641[details]
Proposed patch
Hi Rich,
Are you able to try out this patch and see if it solves the problem ?
Cheers
Nick
Comment 9Richard W.M. Jones
2021-04-26 16:19:16 UTC
I can.
Actually I went about it in a different way - I manually fixed up
commit 6184480d7ce1bc on top of mingw-binutils 2.34 and I'm testing
that out at the moment.
Your patch looks really very different though - is it derived from
something else upstream?
(In reply to Richard W.M. Jones from comment #9)
> I can.
>
> Actually I went about it in a different way - I manually fixed up
> commit 6184480d7ce1bc on top of mingw-binutils 2.34 and I'm testing
> that out at the moment.
>
> Your patch looks really very different though - is it derived from
> something else upstream?
Yes - it is based on comparing the very latest version of the upstream sources of the files affected (arsup.c, rename.c, etc) with the current c9s sources. If I remember correctly the fix for 27270 works, but also causes some build problems on Windows machines, and with recent versions of gcc and clang. Hence I thought that synchronizing might be best.
If your solution works, and presumably is simpler, then lets go with that. I am all for keeping things simple.
Cheers
Nick
Comment 11Richard W.M. Jones
2021-04-26 16:29:16 UTC