Keeping rtems-gcc-head-newlib-head.cfg up to date

Tools Source Builder
1

Anyone know if there is a practical solution to having the gcc_version in rtems/config/tools/rtems-gcc-head-newlib-head.cfg point to master instead of a specific commit? Right now the problem is that the sha512 hash will be different which will fail the build but maybe it’s not necessary to have a hash check for this specific configuration :thinking:

I’m asking because the current commit being pointed at (550241) dates back from September 2024 so it’s pretty old. On the other hand it would be maybe too much effort to try to keep this configuration “up-to-date”

I think this is especially relevant for RISC-V as some instructions (from newer extensions) are only supported on the master branch of GCC right now.

2

I’m not too aware of this situation but isn’t this what next and edge version(s) of GCC are useful for?

They were added so we could build against them for testing, would neither of those work for you? They will eventually become the stable version in the future plus it gets someone to test those versions. :slight_smile:

3

@kiwichris should know if it is possible to not have a hash.

This would be “edge” in the RSB. “next” refers to forward leaning releases. A number (currently 7) refers to the most stable configuration. Next allows safe exploration before bumping a gcc, etc version.

There would be value in this for testing. I have rtems-cron-helpers at my GitHub which know next and 7. They would need to be taught about edge. Then it would be easy to add them to the cron sweeps on about 6-8 hosts which report to the build@ mailing list.

4

The RSB supports git commands and you can make it access a Git repo. We have moved away from doing this for a few reasons:

  1. Git repos in configurations slows down scanning and downloading all the sources. This is done when making a release or update the RTEMS file cache.
  2. The hash in the configuration is a known build point. The HEAD tools are considered unstable and user beware however at least one person, the commit author, has built an architecture.

GitLab provides a low overhead way to commit and get a hash merged.

I have added a new topic on Separate RSB Configurations to help explain how to use those to manage a git based build of GCC head.

5

It does but I prefer, as just explained, we do not have them in the RSB repo any more. The only one left is the Xilinx QEMU repo.

6

But for edge git master makes sense. That’s what we wanted edge for.

7

An HTTP link to pull a tar file down may work but you will need to figure out how to deal with the file cache and the file’s checksum.

8

If removing the hash check is not a possibility then I don’t really see a solution except for updating it manually from time to time.

I managed to build both RISC-V and SPARC tools from GCC commit 73a2a9d6 (dated August 22nd 2025).

Trying with a commit from today (304d08f), the tools also build for both platforms but I get warnings when building the RTEMS kernel due to a lot of the volatile implementation becoming deprecated with GCC20, see P1152R4 Deprecating volatile for more information on that.

9

A git repo check out is not hash checked as git should handle that side of things. You could add a GCC git configurations like binutils from git has. You would then make a simple external configuration you can use.