Based on my records, all issues that can lead to silent miscompilation because of altered configure probes (autoconf/CMake and a few others) have been addressed, or there are at least Bugzilla bugs filed for them. There could be some gaps due to lack of architecture capture, general rawhide churn, or configure scripts running late during the build, which we do not reach due to a previous build failure. But these gaps should fairly small, I hope. It's also not a new problem—while fixing newly introduced errors, we encountered cases where autoconf probes had already been failing unexpectedly for a long time because of typos or missing #include directives.
I originally wanted to fix the int-conversion issues next. That package set is fairly small (about 60 packages). But it's more or less a coin toss whether the compiler errors is due to a missing cast due to C type system limitations, or indicative of a real problem (typically manifesting as a crash at run time if the code is ever executed). The latter can be quite difficult to fix and may require domain-specific knowledge. Just adding the cast in both cases just obscures the crash or misbehavior in the second case, and robs us of an opportunity to fix this properly. I see what I can do to fix packages, but it's unlikely that it will going to be all of them.
Looking at the calendar and the projected time when GCC 14 will land in the buildroot, I think we missed the window where a GCC 13 version with a preview of these C front end changes would have been beneficial to Fedora developers. It would have also created an awkward issue where __GNUC__ is 13, but the compiler behaves in part like GCC 14. This is relevant if it's necessary to suppress (or treat as warnings) -Wreturn-mismatch diagnostics, which only exist in GCC 14.
This brings me to my final point. We still don't have a solution for Vala. I plan to look at valac soon and see what we can do to keep things at least compiling with GCC 14 (after re-running valac).
Thanks, Florian
On Thu, Dec 21, 2023 at 01:59:59PM +0100, Florian Weimer wrote:
Based on my records, all issues that can lead to silent miscompilation because of altered configure probes (autoconf/CMake and a few others) have been addressed, or there are at least Bugzilla bugs filed for them. There could be some gaps due to lack of architecture capture, general rawhide churn, or configure scripts running late during the build, which we do not reach due to a previous build failure. But these gaps should fairly small, I hope. It's also not a new problem—while fixing newly introduced errors, we encountered cases where autoconf probes had already been failing unexpectedly for a long time because of typos or missing #include directives.
I originally wanted to fix the int-conversion issues next. That package set is fairly small (about 60 packages).
Do you have a list of affected packages?
Rich.
But it's more or less a coin toss whether the compiler errors is due to a missing cast due to C type system limitations, or indicative of a real problem (typically manifesting as a crash at run time if the code is ever executed). The latter can be quite difficult to fix and may require domain-specific knowledge. Just adding the cast in both cases just obscures the crash or misbehavior in the second case, and robs us of an opportunity to fix this properly. I see what I can do to fix packages, but it's unlikely that it will going to be all of them.
Looking at the calendar and the projected time when GCC 14 will land in the buildroot, I think we missed the window where a GCC 13 version with a preview of these C front end changes would have been beneficial to Fedora developers. It would have also created an awkward issue where __GNUC__ is 13, but the compiler behaves in part like GCC 14. This is relevant if it's necessary to suppress (or treat as warnings) -Wreturn-mismatch diagnostics, which only exist in GCC 14.
This brings me to my final point. We still don't have a solution for Vala. I plan to look at valac soon and see what we can do to keep things at least compiling with GCC 14 (after re-running valac).
Thanks, Florian -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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, report it: https://pagure.io/fedora-infrastructure/new_issue
* Richard W. M. Jones:
On Thu, Dec 21, 2023 at 01:59:59PM +0100, Florian Weimer wrote:
Based on my records, all issues that can lead to silent miscompilation because of altered configure probes (autoconf/CMake and a few others) have been addressed, or there are at least Bugzilla bugs filed for them. There could be some gaps due to lack of architecture capture, general rawhide churn, or configure scripts running late during the build, which we do not reach due to a previous build failure. But these gaps should fairly small, I hope. It's also not a new problem—while fixing newly introduced errors, we encountered cases where autoconf probes had already been failing unexpectedly for a long time because of typos or missing #include directives.
I originally wanted to fix the int-conversion issues next. That package set is fairly small (about 60 packages).
Do you have a list of affected packages?
This is the list:
Maintainers by package: BitchX kme rdieter adobe-afdko petersen vishalvvr autoconf fberat fjanus jnovy kasal praiskup ttomecek ceph branto kkeithle ktdreyer clearsilver limb pwouters curlftpfs aekoroglu ffmpeg asn ngompa rathann fluent-bit bkircher foma vpv glib2 alexl caolanm mclasen rhughes rstrode glusterfs-coreutils anoopcs devos kkeithle grass devrim jonathanspw neteler gtk-sharp2 caolanm laxathom rhughes rstrode tpokorra gtk-v4l huzaifas gutenprint jpopelka jridky twaugh zdohnal java-1.8.0-openjdk-portable ahughes jandrlik jhuttana jvanek libdb fjanus hhorak mmuzila pkubat libfreenect jkastner kathenas kwizart rmattes libkdumpfile dcavalca salimma libmpd adrian nonamedotc libprelude fab limb totol libskk ueno libsmi jsafrane rvokal spot libtrash kdudka lzaoral svashisht libx86 jcpunk linhpsdr jskarvad mapserver devrim jujens pali smani opendbx mdomsch openhpi rdossant sharkcz openjfx deamn openscap evgenyz jcerny matyc mmarhefk rebus vpolasek wsato paps tagoh pcb-rnd avigne perl-XML-Bare cicku eseyman poke defolos mikelo2 python-axolotl-curve25519 principis python-kadmin limb python-multidict athmane carlwgeorge fab python-poetry-core churchyard thrnciar python-pyopengl swt2c python-subvertpy fab python3-postgresql hhorak raptor2 rdieter rep-gtk kimheino ruby-gnome2 mtasaka rubygem-glu mtasaka rubygem-serialport aeperezt rubygem-xmlparser schwicke schedtool dcavalca drago01 skf mtasaka ski sharkcz squeak-vm jskarvad ssmtp wolfy tcl-signal orion totem-pl-parser kalev nacho xen jforbes myoung zbar limb mchehab slaanesh zziplib abbra jamartis
Thanks, Florian
On Fri, Dec 22, 2023 at 02:18:54PM +0100, Florian Weimer wrote:
gutenprint jpopelka jridky twaugh zdohnal
...FWIW as of a few minutes ago this should be resolved upstream.
- Solomon
* Solomon Peachy via devel:
On Fri, Dec 22, 2023 at 02:18:54PM +0100, Florian Weimer wrote:
gutenprint jpopelka jridky twaugh zdohnal
...FWIW as of a few minutes ago this should be resolved upstream.
Thanks, I can confirm this fixes the issue for the Fedora package as well. Should I push this to rawhide? It makes tracking easier for us.
Florian
On Fri, Dec 22, 2023 at 10:27:55PM +0100, Florian Weimer wrote:
gutenprint jpopelka jridky twaugh zdohnal
...FWIW as of a few minutes ago this should be resolved upstream.
Thanks, I can confirm this fixes the issue for the Fedora package as well. Should I push this to rawhide? It makes tracking easier for us.
Yes please!
There's no good reason for not having rawhide track Gutenprint upstream.
IMO it should get pulled into current Fedora versions too; the first thing I tell anyone reporting an issue is to rebuild from current sources. (Granted most of those users are on EL/LTS-type distros..)
- Solomon
* Solomon Peachy via devel:
On Fri, Dec 22, 2023 at 10:27:55PM +0100, Florian Weimer wrote:
gutenprint jpopelka jridky twaugh zdohnal
...FWIW as of a few minutes ago this should be resolved upstream.
Thanks, I can confirm this fixes the issue for the Fedora package as well. Should I push this to rawhide? It makes tracking easier for us.
Yes please!
There's no good reason for not having rawhide track Gutenprint upstream.
IMO it should get pulled into current Fedora versions too; the first thing I tell anyone reporting an issue is to rebuild from current sources. (Granted most of those users are on EL/LTS-type distros..)
Oh, I meant to backport just this one fix. I'll look into that later this week.
Thanks, Florian