Testing 7/main with GCC 15

Tools Source Builder
1

This topic is for testing 7/main with GCC 15.This includes removing errors, warnings, and fixing issues in add-ons and applications. Help is needed.

2

EDIT: See updated post made on 13 August 2025.

Updating GCC and other tools tends to expose new warnings and errors. @opticron and I have been fixing warnings in rtems and the networking packages (libbsd, lwip, and net services). There are still some warnings/errors in RTEMS itself which I have asked specific people for help with. We would like to branch RTEMS 7 with GCC 15 before GCC 16 is released. Feedback is needed for RTEMS and networking on real hardware along with compiling user applications and their dependencies.

Many of the warnings for RTEMS 6 have been fixed on 7/main as reflected in the table below which is current status as of 3 Aug 2025.

RTEMS 6 w/GCC 13 RTEMS 7 w//GCC 13 RTEMS 7 w/GCC 15
BSPs Total 222 189 189
BSPs w/Errors Building 4 3 3
BSPs w/o Warnings 63 145 145
BSPs w/ Warnings 159 44 44
Unique Warnings 532 5 5

You can build a GCC 15 tool chain for RTEMS 7 by using next/rtems-ARCH instead of 7/rtems-ARCH with the RSB (e.g. sb-set-builder). You likely want to use a different installation prefix. This will give you ARCH-rtems7 tools with GCC 15 instead of GCC 13. Proceed to build everything else as you normally do.

This is the over-arching ticket about updating RTEMS 7/main to use GCC 15 by default:

  • Update main to GCC 15 - Overall issue to switch 7 from GCC 13 to GCC 15. Note: Reports from building all BSPs for 6, 7, and next are attached to this issue.

The following specific issues have been filed and are still open:

Help is appreciated to ensure that user applications and their dependencies are working. If you find warnings or errors, please report them.

3

Is there any suggested workflow on testing? How do you get the 15 tools? What happens if you find a problem, open an issue?

4

The workflow to build the tools, network stacks, and add-on libraries is exactly the same if you build tools with the RSB by hand (e.g. sb-set-builder). Just make sure the gcc 15 tools are first in your PATH or that prefix is in the tools argument. The only difference as I mentioned is that you want to build next/rtems-ARCH instead of 7/rtems-ARCH. The installed tools will have ARCH-rtems7 in the name. This is why installing to a different prefix is probably wise for most people.

Reporting issues is another problem. How about just put “(GCC 15)” in the subject? I do not see having a tag per gcc version until the end of time.

And please make sure that it was introduced by GCC 15. A lot of what I blamed on GCC 14/15 was because we ignored issues with GCC 13 and likely earlier.

1 Like
5

Overnight build sweep results for FreeBSD 14.3 rtems-bsp-builder rtems7
look like my artisan crafted by-hand results.

Results for the sweep before that had build issues from the move of third-party code to contrib/.

6

Current status as of 13 August 2025.

Updating GCC and other tools tends to expose new warnings and errors. @opticron and I have been fixing warnings in rtems and the networking packages (libbsd, lwip, and net services). As of this post, there are no warnings left for rtems main (e.g. 7) with GCC 13 or 15. Thanks to @sebhub for fixing a couple of odd warnings that had lingered.

There are still some errors in RTEMS itself which I have asked specific people for help with. We would like to branch RTEMS 7 with GCC 15 before GCC 16 is released. Feedback is needed for RTEMS and networking on real hardware along with compiling user applications and their dependencies.

There are no warnings 7/main as reflected in the table below which is current status as of 13 Aug 2025. If someone wants specific warnings fixed on RTEMS 6, the change will need to be backported.

RTEMS 6 w/GCC 13 RTEMS 7 w//GCC 13 RTEMS 7 w/GCC 15
BSPs Total 222 190 190
BSPs w/Errors Building 4 3 3
BSPs w/o Warnings 63 190 190
BSPs w/ Warnings 159 0 0
Unique Warnings 532 0 0

Now that 7/main has no warnings, we can discuss enabling -Werror by default. This should help prevent new warnings being introduced by code changes.

You can build a GCC 15 tool chain for RTEMS 7 by using next/rtems-ARCH instead of 7/rtems-ARCH with the RSB (e.g. sb-set-builder). You likely want to use a different installation prefix. This will give you ARCH-rtems7 tools with GCC 15 instead of GCC 13. Proceed to build everything else as you normally do.

This is the over-arching ticket about updating RTEMS 7/main to use GCC 15 by default:

  • Update main to GCC 15 - Overall issue to switch 7 from GCC 13 to GCC 15. **Note: Reports from building all BSPs for 6, 7, and next are attached to this issue. **

This is the only outstanding issue and it is a build error for multiple BSPs:

Help is appreciated to ensure that user applications and their dependencies are working. If you find warnings or errors, please report them.

7

Just following up that this effort has been successful. Building with GCC 15 is now warning free and testing has not turned up any issues. A manual “cron” build sweep has been run and the GCC 15 “next tools” run needs to be added to the OAR build farm. But all looks good.

8

Hi Joel and team,

I’m an incoming GSoC student testing 7/main on Arch (GCC 15.2.1, Python 3.14.3). I wanted to contribute two workarounds I needed to get the ERC32 BSP to build and test on my laptop.

  1. GCC 15 - In addition to the ‘gmp’ ‘elektronik’ issue noted above, GCC threw ‘discarded-qualifiers’ as a hard error, which halted the RSB toolchain build. Instead of patching source code, I used a global compiler wrapper script to intercept the ‘gcc’ call and inject ‘-Wno-error=discarded-qualifiers’ via ‘$@’. Forcing the RSB to use this wrapper in my zsh ‘$PATH’ downgraded the errors to warnings and allowed the build to complete.

  2. Python 3.14 Testing Framework Failure
    The standard library no longer contains ‘telnetlib’. Running ‘rtems-test’ failed with an ‘ImportError’. I bypassed this without touching source code or downgrading python by creating a local venv for the testing phase and installing a third party backport (‘pip install telnetlib-313-and-up’).

Hopefully this helps others who are trying to spin up test environments on rolling release distros.

(AI Transparency note: I prompted Google Gemini for help on the compiler wrapper script in point 1, my prompt was “I’m getting these discarded-qualifiers errors on my build [pasted terminal output] and I can’t seem to make the compiler respect my flags, can I force this?”)

9

@kiwichris @opticron any advice on the Python telnet issue?

The rsb flags for the packages which won’t compile with gcc 15 could include configure options they use to disable warnings as errors.

Unfortunately using a native gcc that is newer than the packages you are compiling is often a way to find things that need fixing in third party packages. Are there newer versions of those?

10

I just checked the logs from my failed build without the wrapper. One of the primary culprits is the Device Tree Compiler, ‘dtc-1.7.2’, failing in ‘libfdt/fdt_overlay.c’ on lines 424 and 434.

 libfdt/fdt_overlay.c: In function 'overlay_fixup_phandle':

libfdt/fdt_overlay.c:424:21: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]

  424 |                 sep = memchr(fixup_str, ':', fixup_len);

      |                     ^

libfdt/fdt_overlay.c:434:21: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]

  434 |                 sep = memchr(name, ':', fixup_len);

      |                     ^

cc1: all warnings being treated as errors

I checked upstream, and 1.7.2 is currently the latest stable release.

Just wanted to send a heads up to hopefully save everyone some time, I’ll keep combing and report back if I find others.>

I opened an upstream error with them here:

11

@opticron has posted a pip work around. I am not sure where it is.

I plan to support the telnet protocol internally. A simple telnet connector so we can continue to support remote serial proxies.

12

I don’t remember pip being involved. Some platforms have a package that brings back telnetlib for later versions of python where it was removed. There should be an issue on rtems-tools about this.

13

Quick update on the ‘dtc’ GCC issue, I opened the issue upstream and David Gibson replied almost immediately. The fix is already in their development branch, and he mentioned my report is another push for them to tag a new stable release soon.