gcc: update to 14.2.0.

[oreo639]

Testing the changes

• I tested the changes in this PR: briefly

[ci skip]

Known packages that need to be updated/fixed for gcc 14:

• python3-lxml python3-lxml: update to 5.3.0. #53011
• xmlto xmlto: update to 0.0.29 #53013
• runit runit: update to 2.2.0. #52408
• ntp
• libsasl
• nvi (done in this pr)
• xbps
• db (done in this pr)
• zsh 1f3cb3a
• gtk+
• gtk+3 gtk+3: update to 3.24.49. #54187
• libaom
• perl-Tk
• gnu-efi-libs gnu-efi-libs: update to 4.0.0. #54615
• syslinux
• recode
• libcdio
• libcddb
• vim
• vmaf

Known packages that need to be updated for gcc 14 and musl (mostly basename):

• elfutils elfutils: update to 0.192. #54566
• iproute iproute2: update to 6.13.0. #54567
• attr fa60f8b
• kmod 54b0270
• sane sane: update to 1.3.1. #54614
• mdadm
• pulseaudio (broken due to configure checks detecting presence of open64, this is fixed in musl 1.2.x bminor/musl@246f1c8 bminor/musl@50ab830)
• gpm

gcc 14 introduces some breaking changes, the most notable of which is the introduction of new C99+ errors. This needs to be tested to catch breakages (note that -fpermissive was also added and can be added to packages as needed).

Note that this doesn't just affect applications but also configuration tests, so some test code that might have been considered conformant C99 with gcc 13 may now be be rejected as ill-formed causing misconfiguration.

On the other hand this also results in some packages, (e.g. on musl) now erroring during compile when built without including the correct basename declaration instead of segfaulting later due to implicit pointer truncation. This is good, but ofc, packages need to be checked for this.

https://gcc.gnu.org/gcc-14/changes.html
https://gcc.gnu.org/gcc-14/porting_to.html

Note that distros like Fedora, have already done a lot of work to audit packages for configuration changes and breakages: https://fedoraproject.org/wiki/Changes/PortingToModernC
If you are maintaining a package, feel free to check if there are patches related to gcc14 or the new C99 errors in Fedora or upstream.

If you are a package maintainer, and have the ability to, please test your packages with gcc 14 to verify no configuration changes occur.

[Calandracas606]

gcc is working for me

i've added --enable-host-pie, and --enable-host-bind-now to my build, and removed nopie. maybe void should consider adding those configure args too.

[oreo639]

i've added --enable-host-pie, and --enable-host-bind-now to my build, and removed nopie. maybe void should consider adding those configure args too.

Thanks for pointing those out.

Keep in mind those flags only apply to the host executables (e.g. /usr/bin/gcc, cc1, cc1plus, etc. as opposed to the libraries or the default flags when compiling).
Those flags are relatively new, and looking upstream there is a patch for a runtime issue caused by --enable-host-pie on PPC gcc-mirror/gcc@4cf2de9 so it might make sense to give more time for those regressions to get found and ironed out before enabling.

The only distro that enables them by default atm, afaict, is RHEL (whereas it is disabled when building gcc for Fedora).
Feel free to let me know if I am missing something.

Edit: At least in Fedora's case, they are disabled for performance reasons, although I'm not sure how big the difference is.

[Calandracas606]

The only distro that enables them by default atm, afaict, is RHEL (whereas it is disabled when building gcc for Fedora).

out of curiosity, where can one find RedHat RMP specs? I've had trouble locating them in the past

[oreo639]

out of curiosity, where can one find RedHat RMP specs? I've had trouble locating them in the past

This is what I was referring to: https://src.fedoraproject.org/rpms/gcc/c/20746dd85fbe810c19ef7e6dea76d3a110bb4a4d

[Calandracas606]

I've been using this for quite a while now.

I used this patch to work around one issue I encountered, although I think its included in newer bugfix releases

From 99a1fe6c12c733fe4923a75a79d09a66ff8abcec Mon Sep 17 00:00:00 2001
From: Jonathan Wakely <[email protected]>
Date: Wed, 12 Jun 2024 16:47:17 +0100
Subject: [PATCH] libstdc++: Fix unwanted #pragma messages from PSTL headers
 [PR113376]

When we rebased the PSTL on upstream, in r14-2109-g3162ca09dbdc2e, a
change to how _PSTL_USAGE_WARNINGS is set was missed out, but the change
to how it's tested was included. This means that the macro is always
defined, so testing it with #ifdef (instead of using #if to test its
value) doesn't work as intended.

Revert the test to use #if again, since that part of the upstream change
was unnecessary in the first place (the macro is always defined, so
there's no need to use #ifdef to avoid -Wundef warnings).

libstdc++-v3/ChangeLog:

	PR libstdc++/113376
	* include/pstl/pstl_config.h: Use #if instead of #ifdef to test
	the _PSTL_USAGE_WARNINGS macro.
---
 libstdc++-v3/include/pstl/pstl_config.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/pstl/pstl_config.h b/libstdc++-v3/include/pstl/pstl_config.h
index 7157a8a492ed..6fae15460eac 100644
--- a/libstdc++-v3/include/pstl/pstl_config.h
+++ b/libstdc++-v3/include/pstl/pstl_config.h
@@ -177,7 +177,7 @@
 
 #define _PSTL_PRAGMA_MESSAGE_IMPL(x) _PSTL_PRAGMA(message(_PSTL_STRING_CONCAT(_PSTL_PRAGMA_LOCATION, x)))
 
-#if defined(_PSTL_USAGE_WARNINGS)
+#if _PSTL_USAGE_WARNINGS
 #    define _PSTL_PRAGMA_MESSAGE(x) _PSTL_PRAGMA_MESSAGE_IMPL(x)
 #    define _PSTL_PRAGMA_MESSAGE_POLICIES(x) _PSTL_PRAGMA_MESSAGE_IMPL(x)
 #else
-- 
2.43.5

Other than that, I've also been using the aforementioned --enable-host-pie, --enable-host-bind-now, and removed nopie

[Vinfall]

Off-topic: quite surprising that Void still does not have gcc-14 :(

[leahneukirchen]

Should we go for glibc 2.41 at the same time?

[MouadCharradi]

With runit-2.2.0 update being merged.
When do you think it's a good time to merge this PR?

[oreo639]

I got busy and never completed testing everything (just the base-system packages with -N on x86_64-glibc). I will start testing again after I finish the GNOME 47 stuff and update the list accordingly.