Build issues with GCC15

elektronik · July 8, 2025, 3:41am

Hello all,

I am attempting to follow the instructions to build RTEMS using the source builder.

My build/development machine is an x86-64 machine running an up-to-date and upgraded version of Arch Linux.

Unfortunately, my build fails when invoking the following command:

../source-builder/sb-set-builder --log=build-log.txt --prefix=$HOME/rtems/compiler/7 --warn-all --targetcflags -std=c17 7/rtems-arm

with the following output and error message:

RTEMS Source Builder - Set Builder, 7 (599b400823d8)
warning: dir: not found: (_buildcxcdir) /home/nikola/rtems/rtems-source-builder/rtems/build/-cxc
warning: dir: not found: (_buildxcdir) /home/nikola/rtems/rtems-source-builder/rtems/build/-xc
warning: dir: not found: (_configdir) /home/nikola/rtems/rtems-source-builder/rtems/config:/home/nikola/rtems/rtems-source-builder/source-builder/config:/home/nikola/rtems/rtems-source-builder/bare/config:/home/nikola/rtems/rtems-source-builder/rtems/config
warning: dir: not found: (_patchdir) /home/nikola/rtems/rtems-source-builder/rtems/patches:/home/nikola/rtems/rtems-source-builder/source-builder/patches
warning: dir: not found: (_tardir) /home/nikola/rtems/rtems-source-builder/rtems/tar
Build Set: 7/rtems-arm
Build Set: tools/rtems-default-tools.bset
config: devel/dtc-1.7.2-1.cfg
package: dtc-1.7.2-x86_64-linux-gnu-1
building: dtc-1.7.2-x86_64-linux-gnu-1
sizes: dtc-1.7.2-x86_64-linux-gnu-1: 4.171MB (installed: 1.116MB)
cleaning: dtc-1.7.2-x86_64-linux-gnu-1
reporting: devel/dtc-1.7.2-1.cfg -> dtc-1.7.2-x86_64-linux-gnu-1.txt
reporting: devel/dtc-1.7.2-1.cfg -> dtc-1.7.2-x86_64-linux-gnu-1.xml
Build Set: devel/expat-internal.bset
config: devel/expat-2.5.0-1.cfg
package: expat-2.5.0-x86_64-linux-gnu-1
building: expat-2.5.0-x86_64-linux-gnu-1
sizes: expat-2.5.0-x86_64-linux-gnu-1: 8.191MB (installed: 0.000B)
cleaning: expat-2.5.0-x86_64-linux-gnu-1
cleaning: expat-2.5.0-x86_64-linux-gnu-1
Build Set: Time 0:00:06.339480
Build Set: devel/gmp-internal.bset
config: devel/gmp-6.3.0.cfg
package: gmp-6.3.0-x86_64-linux-gnu-1
building: gmp-6.3.0-x86_64-linux-gnu-1
error: building gmp-6.3.0-x86_64-linux-gnu-1
Build FAILED
  See error report: rsb-report-gmp-6.3.0-x86_64-linux-gnu-1.txt
  Note: In some cases the error appears only in
  the complete build log (see --log option)
error: building gmp-6.3.0-x86_64-linux-gnu-1
Build Set: Time 0:00:01.537105
error: building gmp-6.3.0-x86_64-linux-gnu-1
Build Set: Time 0:00:16.636439
error: building gmp-6.3.0-x86_64-linux-gnu-1
Build Set: Time 0:00:16.637604
Build FAILED

I dug through the generated log file for failing gmp build and found the following cause reported:


checking compiler gcc -O2 -g -pipe -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000/devel/gmp-internal/home/nikola/rtems/compiler/7/include -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000-internal/include -O2 -pedantic -fomit-frame-pointer -m64 ... no, long long reliability test 1
checking ABI=x32
checking compiler gcc -O2 -g -pipe -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000/devel/gmp-internal/home/nikola/rtems/compiler/7/include -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000-internal/include -O2 -pedantic -fomit-frame-pointer -mx32 ... no
checking ABI=32
checking compiler gcc -O2 -g -pipe -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000/devel/gmp-internal/home/nikola/rtems/compiler/7/include -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000-internal/include -m32 -O2 -pedantic -fomit-frame-pointer ... no, long long reliability test 1
checking compiler gcc -O2 -g -pipe -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000/devel/gmp-internal/home/nikola/rtems/compiler/7/include -I/home/nikola/rtems/rtems-source-builder/rtems/build/tmp/sb-1000-internal/include -O2 -pedantic -fomit-frame-pointer ... no, long long reliability test 1
configure: error: could not find a working compiler, see config.log for details

A bit of digging on github and other corners of the internet has lead to a few other instances of the same problem being reported:

github.com/splintchecker/splint

Fails to build with gcc15/C23

opened 12:29PM - 04 May 25 UTC

heirecka

`gcc version 15.1.0 (GCC)` ``` Compiling mtgrammar.c... mtgrammar.c: In functio…n 'mtparse': mtgrammar.c:63:15: error: too many arguments to function 'mtlex'; expected 0, have 1 63 | #define yylex mtlex | ^~~~~ mtgrammar.c:659:33: note: in expansion of macro 'yylex' 659 | # define YYLEX yylex (&yylval) | ^~~~~ mtgrammar.c:1017:16: note: in expansion of macro 'YYLEX' 1017 | yychar = YYLEX; | ^~~~~ mtgrammar.c:135:12: note: declared here 135 | extern int mtlex () ; | ^~~~~ mtgrammar.c:139:37: error: too many arguments to function 'yyprint'; expected 0, have 3 139 | # define YYPRINT(file, type, value) yyprint (file, type, value) | ^~~~~~~ mtgrammar.c:1043:11: note: in expansion of macro 'YYPRINT' 1043 | YYPRINT (stderr, yychar, yylval); | ^~~~~~~ mtgrammar.c:136:13: note: declared here 136 | static void yyprint (/*FILE *p_file, int p_type, YYSTYPE p_value */); | ^~~~~~~ mtgrammar.c: At top level: mtgrammar.c:1669:13: error: conflicting types for 'yyprint'; have 'void(FILE *, int, yystype)' 1669 | static void yyprint (FILE *file, int type, YYSTYPE value) | ^~~~~~~ mtgrammar.c:136:13: note: previous declaration of 'yyprint' with type 'void(void)' 136 | static void yyprint (/*FILE *p_file, int p_type, YYSTYPE p_value */); | ^~~~~~~ mtgrammar.c:136:13: warning: 'yyprint' used but never defined make[3]: Leaving directory '/var/tmp/paludis/build/dev-util-splint-3.1.2/work/splint-3.1.2/src' make[3]: *** [Makefile:1162: mtgrammar.o] Error 1 make[2]: *** [Makefile:1105: Headers/flag_codes.gen] Error 2 make[2]: Leaving directory '/var/tmp/paludis/build/dev-util-splint-3.1.2/work/splint-3.1.2/src' make[1]: *** [Makefile:175: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/paludis/build/dev-util-splint-3.1.2/work/splint-3.1.2' make: *** [Makefile:130: all] Error 2 ```

It appears that GCC15 defaults to using C23 which doesn’t like portions of the GMP source code. To test whether this is the case, I forced gcc to use the C17 standard via setting the CC environment variable in my bash profile. I can successfully run the configure script and makefile manually via terminal after doing so. Unfortunately the error seems to persist despite my attempts to inject a flag to force the use of the C17 standard when running the source builder. I have also tried to force gcc to use the C17 standard by using an alias for x86_64-linux-gnu-gcc (x86_64-linux-gnu-gcc=‘x86_64-linux-gnu-gcc -std=c17’), but with no success.

I’m still learning my way around Linux, so I’m a bit stuck for ideas on what to try next. If anyone has any advice on how to work around this, it would be much appreciated.

Regards,

elektronik

kiwichris · July 9, 2025, 2:15am

Is there a version of GMP that supports C23?

elektronik · July 9, 2025, 2:48am

After a bit more digging, it appears that the GMP maintainers discovered and patched this problem and uploaded an unofficial patch to their compiler-explorer on github.

https://gmplib.org/list-archives/gmp-bugs/2025-February/005559.html

github.com/compiler-explorer/gcc-cross-builder

build/patches/crosstool-ng/0001-gcc-15-fix.patch

main

From 80a11dc3593a32a9ce14427509ed6b49ae8c6fe5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc=20Poulhi=C3=A8s?= <dkm@kataplop.net>
Date: Tue, 4 Feb 2025 08:35:16 +0100
Subject: [PATCH] gcc 15 fix

---
 packages/gmp/6.3.0/configure-compilation-error.patch | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 packages/gmp/6.3.0/configure-compilation-error.patch

diff --git a/packages/gmp/6.3.0/configure-compilation-error.patch b/packages/gmp/6.3.0/configure-compilation-error.patch
new file mode 100644
index 00000000..1cf10070
--- /dev/null
+++ b/packages/gmp/6.3.0/configure-compilation-error.patch
@@ -0,0 +1,11 @@
+--- gmp-6.3.0/configure	2023-07-29 15:42:22.000000000 +0200
++++ gmp/configure	2025-02-03 22:00:33.567817886 +0100
+@@ -6568,7 +6566,7 @@
+

This file has been truncated. show original

I have checked the gmp.cfg script and found that the tarball pulled from the website was uploaded in 2023; long before GCC15.1’s release earlier this year. This script also appears to invoke the configure and build steps, so maybe I can force the injection of the appropriate flag to force the use of C17 here. Please let me know if I’m on the right track and if you have any suggestions on how to perform this (if I am correct).

elektronik · July 9, 2025, 4:13am

SOLVED!

Adding CFLAGS='-std=c17' to gmp.cfg before invoking the configure script does the trick.


%build
  build_top=$(pwd)

  cd gmp-%{gmp_version}

  %{host_build_flags}

  CFLAGS='-std=c17'

  ./configure \
    --build=%{_build} --host=%{_host} \
    --verbose \
    --prefix=%{gmp_prefix} --bindir=%{gmp_bindir} \
    --exec-prefix=%{gmp_exec_prefix} \
    --includedir=%{gmp_includedir} --libdir=%{gmp_libdir} \
    --mandir=%{gmp_mandir} --infodir=%{gmp_infodir} \
    --disable-shared \
    %{gmp_extra_options}

The tool suite is successfully building now.

Update:

Confirm mission accomplished.

amar · July 17, 2025, 2:29pm

Awesome! Thanks for posting your results.

Andrea · August 20, 2025, 9:39pm

Hi everyone,

I’m new to the forum and I just signed up to thank @elektronik for the solution: I’ve spent the best part of an evening trying to pass the correct flag to the build script. Btw I really think this should be patched in the future releases.

amar · August 20, 2025, 11:01pm

Hi there Andrea, welcome! There is an open MR to address this issue:

This MR adds a big warning for users.

kiwichris · August 20, 2025, 11:27pm

My concern with the MR is clang support and how fragile the version check might be. I have added a comment to the MR.