|
|
Subscribe / Log in / New account

GCC 14.1 released

GCC 14.1 released

Posted May 8, 2024 20:06 UTC (Wed) by fw (subscriber, #26023)
In reply to: GCC 14.1 released by sam_c
Parent article: GCC 14.1 released

I expect some 200 or 300 build failures to remain in Fedora. We didn't originally plan to do all the int-conversion and incompatible-pointer-types cleanups (and return-mismatch didn't even exist yet), but feedback at GNU Tools Cauldron and elsewhere was that we shouldn't do this piecemeal. That left us a bit in a bind from a Fedora perspective. I think we managed to get it down quite close to the usual failure level if you do mass rebuilds every six months (just due to rebuilds picking up incompatible new development in the rest of the distribution).

Towards the release, it became increasingly unclear if a build failure was a Modern C problem, or something else. For example, removing a function declaration from an installed header file used to be a mostly source-compatible change (but not necessarily ABI-compatible if the function returned a double or a pointer). Likewise adding a new argument to a callback function was de-facto source-compatible (and probably ABI-compatible on our targets). Now these result in compilation failures. If I recall correctly, libxml2 2.12 had quite a few changes like that. Are the fixes required work items for the libxml2 2.12 transition, or are they part of the GCC 14 cleanups?

Even before all the fixes, the failure rate wasn't that alarming from a distribution perspective. (As I mentioned, things break all the time, so you fix them and move on.) The more significant concern was that people who start using GCC 14 would no longer be able to build a fair number of generally well-maintained upstream projects. That's why we put so much effort into upstreaming our patches.


to post comments

GCC 14.1 released

Posted May 8, 2024 20:38 UTC (Wed) by sam_c (subscriber, #139836) [Link]

Yes, and no doubt we'll have a new slew of failures with e.g. new Perl and so on, as the year goes on. You're right - I should be less pessimistic :)

GCC 14.1 released

Posted May 12, 2024 20:04 UTC (Sun) by ballombe (subscriber, #9523) [Link] (2 responses)

... and they will no more be able to build older releases and older git snapshot for bisecting purpose.

GCC 14.1 released

Posted May 12, 2024 20:13 UTC (Sun) by fw (subscriber, #26023) [Link]

Surely something like CC="gcc -fpermissive" will work for that. The porting advice describers other approaches, too.

GCC 14.1 released

Posted May 13, 2024 9:44 UTC (Mon) by farnz (subscriber, #17727) [Link]

As a tooling matter, this is why I check in rust-toolchain.toml and Cargo.lock on personal Rust projects; that way, as I bisect, I move automatically to the version of tooling I used in the past.

I'm also cautious about having separate commits for changes to these files, so that if I do bisect, and land on one of them, it's clear that I'm seeing an impact from either a toolchain change, or a dependency change.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds