Groundwork for moving off GCC 13.2.0. Upstream redox-os/gcc has only
redox, redox-8.2.0 and redox-13.2.0, so there is no GCC 14+ with Redox
support to consume -- the port has to be carried by us.
Forced by KDE: KWin (16 files) and plasma-workspace (1 file) use C++23
std::ranges::to and both declare CMAKE_CXX_STANDARD 23. Verified the
current toolchain cannot satisfy that: the fork's libstdc++ has no
__cpp_lib_ranges_to_container and gcc/BASE-VER is 13.2.0, so there is no
hidden 14-ness to exploit. Backporting the call sites was rejected as the
costlier path -- it recurs every KDE release and diverges from upstream
KDE, against 'adapt to upstream, never the reverse'.
Measured surface: the whole Redox port is 13 files. Five are Redox-owned
(redox.h 36 lines, redox.opt 27 lines, three xm-redox.h) and are captured
verbatim under files/. The other eight are *-*-redox* case arms in
config.sub, gcc/config.{gcc,host,build}, libgcc/config.host,
libstdc++-v3/crossconfig.m4, os_defines.h and fixincludes/mkfixinc.sh,
captured with context in registration-hunks.txt. This is a textbook GCC
target port, not a compiler fork.
README records the apply procedure and the measured risks: libstdc++ ABI
change forces a full C++ tree rebuild; mk/prefix.mk currently DOWNLOADS the
toolchain from static.redox-os.org, so building our own is a permanent
ownership cost; relibc's cbindgen headers have a documented history of
fighting GCC and a newer one may reopen it; and mk/prefix.mk hardcodes
'13.2.0' in a path that must be parameterized.
Note gcc/configure and libstdc++-v3/configure also match 'redox' but are
GENERATED -- regenerate from crossconfig.m4, do not hand-edit.
vasilito
c88ddabcdd