GCC 15.1 released

[Posted April 25, 2025 by corbet]

Version 15.1 of the GNU Compiler Collection has been released. Changes include implementing the C23 dialect by default, a number of new C++26 features, experimental support for unsigned integers in Fortran, a new COBOL front end, and more. See the GCC 15 changes page for details.

Modern C Porting

Posted Apr 25, 2025 14:52 UTC (Fri) by NHO (subscriber, #104320) [Link] (11 responses)

Gentoo still has about a hundred of open bugs about compilation failures C23 and C99. Science, games, ancient desktop environments.

I suspect remaining unported packages will get -std=gnu17 slapped onto them. Some of them are hard to port downstream due to, eg. ad-hoc C polymorphism. Some of them are ncurses/gmp definition loop with gmp being dead. But I also hope some of them would get dropped from the tree as affront to programming and build systems.

Modern C Porting

Posted Apr 25, 2025 15:03 UTC (Fri) by ballombe (subscriber, #9523) [Link] (10 responses)

gmp ? do you mean gpm ?

Modern C Porting

Posted Apr 25, 2025 15:16 UTC (Fri) by NHO (subscriber, #104320) [Link] (9 responses)

Console mouse program, yes.

Modern C Porting

Posted Apr 25, 2025 18:14 UTC (Fri) by ballombe (subscriber, #9523) [Link] (8 responses)

If you need an alternative to gpm (but not to libgpm), you can consider consolation.

Modern C Porting

Posted Apr 25, 2025 18:23 UTC (Fri) by NHO (subscriber, #104320) [Link] (7 responses)

No, it's not about alternative. It's about existing packages that use ncurses and gpm and that fail to build with gcc-15 because patching gpm downstream means incompatibility with other distros, and no one wants that.
https://github.com/telmich/gpm/issues/48

Modern C Porting

Posted Apr 25, 2025 18:39 UTC (Fri) by willy (subscriber, #9762) [Link] (6 responses)

How does fixing the prototype create incompatiblity?

Modern C Porting

Posted Apr 25, 2025 18:46 UTC (Fri) by sam_c (subscriber, #139836) [Link] (5 responses)

The incompatibility is in a header installed by gpm. If we unilaterally fix it downstream, that causes confusion if people try to then build that software on other distributions. Patching headers in a downstream-only patch should be done as a last resort.

There's also no guarantee that upstream if they ever wake up will fix it in the same way (could e.g. decide to add a new function that is properly prototyped instead).

Modern C Porting

Posted Apr 25, 2025 19:23 UTC (Fri) by Wol (subscriber, #4433) [Link] (4 responses)

Can't you hijack/fork upstream, and if they do wake up let them merge the two?

Cheers,
Wol

Modern C Porting

Posted Apr 25, 2025 21:01 UTC (Fri) by NHO (subscriber, #104320) [Link] (3 responses)

That requires coordination with other distros. Or we will have oopsies with sudden, inexplicable crashes. Because two GPMs are incompatible.
This also removes backwards compatibility...

Modern C Porting

Posted Apr 26, 2025 7:40 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (1 responses)

Yeah, but isn't using a package from another distro a fringe curiosity now? No distribution supports that, and every one rebuilds its packages very often.

Modern C Porting

Posted Apr 26, 2025 13:19 UTC (Sat) by Wol (subscriber, #4433) [Link]

And if upstream is effectively dead, which is the impression I get, you're basically saying to other distros "we're happy to be the new upstream, for bugfixes etc, unless/until the old upstream wakes up".

What's the point of a dead upstream? How much *extra* effort is it for a distro maintainer to to take over package maintenance, if all they're doing is fixing things like those compiler problems? Then you shouldn't get problems because all distros should be marching to the same beat.

Cheers,
Wol

Modern C Porting

Posted Apr 26, 2025 13:17 UTC (Sat) by hmh (subscriber, #3838) [Link]

Some distros are known to have been only-too-happy to do such "rescue upstream" share-the-patches-using-a-new-upstream efforts in the past. Debian and Fedora come to mind.

All it takes is the maintainers to moderately trust each other, which is usually easy enough if they are (verified to be) long-time downstream maintainers of said packages, and the proposed patches are also easily verified to have been in use for a long time on the distro.

And, of course, one of them to come forward and take the "temporary new upstream" hat. There is no reason it couldn't be the gentoo downstream maintainer doing this, all it takes is for them to have been along for long enough for the others to trust them enough.

And yeah, usually, these efforts come with "this is a temporary fork, should upstream wake up and start merging changes, it will be dropped" notices.