arch/parisc/boot/compressed/Makefile | 2 +- arch/s390/Makefile | 2 +- arch/s390/purgatory/Makefile | 2 +- arch/x86/Makefile | 2 +- arch/x86/boot/compressed/Makefile | 2 +- drivers/firmware/efi/libstub/Makefile | 2 +- kernel/trace/trace_events_synth.c | 3 ++- 7 files changed, 8 insertions(+), 7 deletions(-)
This kernel version doesn't build with GCC 15:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from arch/x86/realmode/rm/wakeup.h:11,
from arch/x86/realmode/rm/wakemain.c:2:
include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
11 | false = 0,
| ^~~~~
include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef'
30 | typedef _Bool bool;
| ^~~~
include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards
include/linux/types.h:30:1: warning: useless type name in empty declaration
30 | typedef _Bool bool;
| ^~~~~~~
I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I
realised this fix was already done in an upstream commit, created before
the GCC 15 release and not mentioning the error I had. This is the first
patch.
When I was investigating my error, I noticed other commits were already
backported to stable versions. They were all adding -std=gnu11 in
different Makefiles. In their commit message, they were mentioning
'gnu11' was picked to use the same as the one from the main Makefile.
But this is not the case in this kernel version. Patch 2 fixes that.
Finally, I noticed an extra warning that I didn't have in v5.15. Patch 3
fixes that.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Alexey Dobriyan (1):
x86/boot: Compile boot code with -std=gnu11 too
Matthieu Baerts (NGI0) (2):
arch: back to -std=gnu89 in < v5.18
tracing: fix declaration-after-statement warning
arch/parisc/boot/compressed/Makefile | 2 +-
arch/s390/Makefile | 2 +-
arch/s390/purgatory/Makefile | 2 +-
arch/x86/Makefile | 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
drivers/firmware/efi/libstub/Makefile | 2 +-
kernel/trace/trace_events_synth.c | 3 ++-
7 files changed, 8 insertions(+), 7 deletions(-)
---
base-commit: a32db271d59d9f35f3a937ac27fcc2db1e029cdc
change-id: 20251017-v5-10-gcc-15-ad2510f784f7
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
On 10/17/25 18:53, Matthieu Baerts (NGI0) wrote: > This kernel version doesn't build with GCC 15: > > In file included from include/uapi/linux/posix_types.h:5, > from include/uapi/linux/types.h:14, > from include/linux/types.h:6, > from arch/x86/realmode/rm/wakeup.h:11, > from arch/x86/realmode/rm/wakemain.c:2: > include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant > 11 | false = 0, > | ^~~~~ > include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards > include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef' > 30 | typedef _Bool bool; > | ^~~~ > include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards > include/linux/types.h:30:1: warning: useless type name in empty declaration > 30 | typedef _Bool bool; > | ^~~~~~~ > > I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I > realised this fix was already done in an upstream commit, created before > the GCC 15 release and not mentioning the error I had. This is the first > patch. > > When I was investigating my error, I noticed other commits were already > backported to stable versions. They were all adding -std=gnu11 in > different Makefiles. In their commit message, they were mentioning > 'gnu11' was picked to use the same as the one from the main Makefile. > But this is not the case in this kernel version. Patch 2 fixes that. > > Finally, I noticed an extra warning that I didn't have in v5.15. Patch 3 > fixes that. > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > --- > Alexey Dobriyan (1): > x86/boot: Compile boot code with -std=gnu11 too > > Matthieu Baerts (NGI0) (2): > arch: back to -std=gnu89 in < v5.18 > tracing: fix declaration-after-statement warning > > arch/parisc/boot/compressed/Makefile | 2 +- > arch/s390/Makefile | 2 +- > arch/s390/purgatory/Makefile | 2 +- > arch/x86/Makefile | 2 +- > arch/x86/boot/compressed/Makefile | 2 +- > drivers/firmware/efi/libstub/Makefile | 2 +- > kernel/trace/trace_events_synth.c | 3 ++- > 7 files changed, 8 insertions(+), 7 deletions(-) > --- > base-commit: a32db271d59d9f35f3a937ac27fcc2db1e029cdc > change-id: 20251017-v5-10-gcc-15-ad2510f784f7 > > Best regards, The last kernel I was able to build with GCC15 was 5.10.245. With 5.10.246 we have again the 'FAILED unresolved symbol filp_close' error. Attached you may find the full build log. 5.4.x and 5.15.x series still compile fine with GCC15. We already had the issue with 5.10.235 back in March: https://lore.kernel.org/stable/b39ca723-16a4-42a2-b8ca-b97d0e4bf7f5@manjaro.org/ -- Best, Philip
On Fri, Oct 17, 2025 at 06:53:24PM +0200, Matthieu Baerts (NGI0) wrote: > This kernel version doesn't build with GCC 15: > > In file included from include/uapi/linux/posix_types.h:5, > from include/uapi/linux/types.h:14, > from include/linux/types.h:6, > from arch/x86/realmode/rm/wakeup.h:11, > from arch/x86/realmode/rm/wakemain.c:2: > include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant > 11 | false = 0, > | ^~~~~ > include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards > include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef' > 30 | typedef _Bool bool; > | ^~~~ > include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards > include/linux/types.h:30:1: warning: useless type name in empty declaration > 30 | typedef _Bool bool; > | ^~~~~~~ > > I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I > realised this fix was already done in an upstream commit, created before > the GCC 15 release and not mentioning the error I had. This is the first > patch. > > When I was investigating my error, I noticed other commits were already > backported to stable versions. They were all adding -std=gnu11 in > different Makefiles. In their commit message, they were mentioning > 'gnu11' was picked to use the same as the one from the main Makefile. > But this is not the case in this kernel version. Patch 2 fixes that. > > Finally, I noticed an extra warning that I didn't have in v5.15. Patch 3 > fixes that. As with 5.4.y, this kernel isn't going to be around all that much longer, and I strongly doubt anyone that relies on it is also using gcc15 with it. Normally near the end of the 6 year window of kernels, we are "stuck" with using older gcc releases with that, and not newer ones, and that's fine, as that's what the users of those kernels are also doing. So I don't think the effort is worth it. gcc14 will be around in distros for the next year so all should be ok here. Just like gcc13 was around long enough for us to keep 4.19.y working just fine with that maximum compiler release as well. thanks, greg k-h
Hi Greg, Thank you for your reply! On 20/10/2025 15:32, Greg Kroah-Hartman wrote: > On Fri, Oct 17, 2025 at 06:53:24PM +0200, Matthieu Baerts (NGI0) wrote: >> This kernel version doesn't build with GCC 15: >> >> In file included from include/uapi/linux/posix_types.h:5, >> from include/uapi/linux/types.h:14, >> from include/linux/types.h:6, >> from arch/x86/realmode/rm/wakeup.h:11, >> from arch/x86/realmode/rm/wakemain.c:2: >> include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant >> 11 | false = 0, >> | ^~~~~ >> include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards >> include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef' >> 30 | typedef _Bool bool; >> | ^~~~ >> include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards >> include/linux/types.h:30:1: warning: useless type name in empty declaration >> 30 | typedef _Bool bool; >> | ^~~~~~~ >> >> I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I >> realised this fix was already done in an upstream commit, created before >> the GCC 15 release and not mentioning the error I had. This is the first >> patch. >> >> When I was investigating my error, I noticed other commits were already >> backported to stable versions. They were all adding -std=gnu11 in >> different Makefiles. In their commit message, they were mentioning >> 'gnu11' was picked to use the same as the one from the main Makefile. >> But this is not the case in this kernel version. Patch 2 fixes that. >> >> Finally, I noticed an extra warning that I didn't have in v5.15. Patch 3 >> fixes that. > > As with 5.4.y, this kernel isn't going to be around all that much > longer, and I strongly doubt anyone that relies on it is also using > gcc15 with it. Normally near the end of the 6 year window of kernels, > we are "stuck" with using older gcc releases with that, and not newer > ones, and that's fine, as that's what the users of those kernels are > also doing. > > So I don't think the effort is worth it. gcc14 will be around in > distros for the next year so all should be ok here. Just like gcc13 was > around long enough for us to keep 4.19.y working just fine with that > maximum compiler release as well. Fine by me, but just to avoid confusions, I would like to add: - Only the first patch fixes the GCC 15 support, and it only adds '-std=gnu11' in x86/boot. All the other GCC 15 specific patches have already been backported, only that one didn't have a Fixes tag and was missing in <= v5.15. - Patch 2/3 fixes the (accidental) switch to C11 standard for some arch. It should not be a problem in v5.10, because GCC minimal version is 4.9 which supports C11 if I'm not mistaken. It is just to be consistent with what is done in the main Makefile, but it can be drop if preferred. - Patch 3/3 is not linked to GCC 15 support, it fixes an ISO C90 warning. Cheers, Matt -- Sponsored by the NGI0 Core fund.
© 2016 - 2025 Red Hat, Inc.