Build failures in RTEMS RSB with GCC 15/16 host compiler

General
1

Environment

  • Command:
    ../source-builder/sb-set-builder \
    --log=build.log \
    --prefix=$HOME/rtems/7 \
    7/rtems-sparc
  • Host compiler: GCC 16.1.1 (Python 3.14.4)
  • Target: sparc-rtems7-gcc-15.2.0

Issue 1: dtc-1.7.2 — -Werror=discarded-qualifiers

Error

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

Root Cause

GCC 15/16 is stricter about memchr returning const void* being assigned
to a char*. The proper fix would be making sep a const char*, but doing so requires further changes since the code writes through the pointer in someplaces, which would break the program. So removing -Werror seemed the appropriate fix.

Fix

--- dtc-1.7.2.orig/Makefile
+++ dtc-1.7.2/Makefile
@@ -21,7 +21,7 @@
 WARNINGS = -Wall -Wpointer-arith -Wcast-qual -Wnested-externs -Wsign-compare \
 	-Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wshadow \
 	-Wsuggest-attribute=format -Wwrite-strings
-CFLAGS = -g -Os $(SHAREDLIB_CFLAGS) -Werror $(WARNINGS) $(EXTRA_CFLAGS)
+CFLAGS = -g -Os $(SHAREDLIB_CFLAGS) $(WARNINGS) $(EXTRA_CFLAGS)

Issue 2: gcc-15.2.0 libcody — char8_t incompatibility with C++23

GCC 15 defaults to -std=c++23. This causes two distinct failures in libcody.

Failure A: S2C() template — cody.hh

Error

../../gcc-15.2.0/libcody/buffer.cc:236:32:
error: no matching function for call to 'S2C(const char8_t [2])'

Cause

In C++23, u8"..." string literals produce const char8_t[] instead of
const char[]. The existing S2C template only accepts const char (&s)[I],
so all S2C(u8"...") call sites fail. This affects not just libcody’s own
files but also gcc/cp/mapper-client.cc and mapper-resolver.cc which
include cody.hh and are always compiled as C++23

Fix

Added a char8_t overload guarded by #if __cplusplus >= 202002L (since
char8_t itself was introduced in C++20):

--- gcc-15.2.0.orig/libcody/cody.hh
+++ gcc-15.2.0/libcody/cody.hh
@@ -54,6 +54,15 @@
   return s[0];
 }

+#if __cplusplus >= 202002L
+template<unsigned I>
+constexpr char S2C (char8_t const (&s)[I])
+{
+  static_assert (I == 2, "only single octet strings may be converted");
+  return static_cast<char>(s[0]);
+}
+#endif
+
 /// Internal buffering class.

The #if __cplusplus >= 202002L guard is necessary because of how the two build systems interact. To fix Failure B (below), we force libcody/Makefile.in to compile with -std=c++17.
As compiling it with gcc15 would cause an error as of the cause stated above.

This means buffer.cc, client.cc etc. are
compiled as C++17 and include cody.hh in a C++17 context where char8_t
does not exist. Without the guard, the overload would cause an “unknown type”
error in that context.

At the same time, gcc/cp/mapper-client.cc and mapper-resolver.cc are part of GCC’s own source and are compiled by GCC’s main Makefile as C++23. They just happen to #include "cody.hh" — but our -std=c++17 flag in libcody/Makefile.in has no effect on them at all.

So the overload in cody.hh is the only thing that can fix mapper-client.cc and mapper-resolver.cc — it is a header fix that travels with the #include regardless of which Makefile is doing the compiling. The guard makes it skip silently in C++17 contexts and activate only in C++20/23 contexts where char8_t is defined.

Failure B: u8 string literals used as std::string — client.cc

Error

../../gcc-15.2.0/libcody/client.cc:100:42:
error: no matching function for call to
'std::string::basic_string(const char8_t [21])'
  100 |   std::string e {u8"communication error:"};

Root Cause

client.cc uses u8"..." literals directly as std::string, const char*,
and in comparisons. In C++23 these are char8_t* which std::string does not accept. Unlike the S2C issue, this cannot be fixed by an overload —
it requires either removing the u8 prefixes or compiling client.cc as
C++17. Since client.cc is only compiled by libcody’s own Makefile.in (not included as a header by other GCC files), forcing -std=c++17 there is safe and targeted.

Fix

--- gcc-15.2.0.orig/libcody/Makefile.in
+++ gcc-15.2.0/libcody/Makefile.in
@@ -21,7 +21,7 @@
 CXXFLAGS := @CXXFLAGS@
 CXXINC := $(filter -I%,@CXX@)
-CXXOPTS := $(CXXFLAGS) @PICFLAG@
+CXXOPTS := $(CXXFLAGS) @PICFLAG@ -std=c++17

Anyone’s guidance is highly praised. Do let me know what could be done instead of what i did?
Should I raise an issue for it ?
@gedare @c-mauderer

2

Hey there Prakahar!
The recent infrastructural changes allow for explicitly setting language standards. MR !246 adds support for setting standard via package config files.

Given that, a series of MRs have been made to fix the errors.
!255 !256 !257