Files
RedBear-OS/local/scripts/build-gcc16-cross.sh
T
vasilito f2b6c1e0ed gcc: port GCC 16.1.0 to the Redox target and install the toolchain
The Redox target port applier claimed validation on 16.1.0 but its
idempotency probe used each block's longest line, which for three blocks
is generic upstream boilerplate. Against a pristine 16.1.0 tree that
silently skipped the libgcc target arms and BOTH crossconfig.m4 arms
(libgcc/config.host and crossconfig.m4 contain zero redox references, yet
the applier reported 'already present'), producing a half-ported tree --
the exact failure the script documents itself as preventing. Probe on the
longest redox-bearing line instead, matched whole.

Two port requirements the original extraction missed, both fatal:

- gcc/config/redox.opt.urls. GCC 16 requires a .opt.urls companion for
  every .opt; s-options fails without it. Contents match what
  regenerate-opt-urls.py emits for these two options, cross-checked
  against the six upstream .opt.urls declaring the same pthread/rdynamic.

- libtool has no redox host. Upstream Redox gets shared libraries from
  recipes/dev/libtool (a Redox-patched libtool 2.5.4-redox-9510) via
  libtoolize during autoreconf, not from GCC's bundled libtool.m4. That
  route does not apply to GCC 16, which bundles 2.2.7-era macros plus its
  own ltgcc.m4. Without redox arms _LT_SYS_DYNAMIC_LINKER leaves
  dynamic_linker=no, libstdc++ builds static-only, and the desktop stack
  cannot link -- libQt6Core.so and every KF6 library carry DT_NEEDED
  libstdc++.so.6. apply-libtool-redox.py registers the four arms that
  matter, verbatim from the Redox libtool macros already in prefix/.

Result: x86_64-unknown-redox-gcc 16.1.0 with libstdc++.so.6.0.35 (SONAME
libstdc++.so.6, NEEDED libc.so.6 + libgcc_s.so.1 -- identical to the
13.2.0 library it replaces, exports a superset up to GLIBCXX_3.4.35).
std::ranges::to now compiles for the Redox target; GCC 13.2.0 fails the
same test, which is what blocked kwin's 16 affected files.

install-gcc16-toolchain.sh installs into all three locations a recipe can
resolve a compiler from -- including ~/.redoxer, which src/cook/script.rs
puts highest on PATH -- and is reversible with --restore. Its cstdlib
strtold patch is guarded; the mk/prefix.mk sed is not, and had applied
that block 17 times to the GCC 13 toolchain.
2026-08-03 12:40:15 +03:00

97 lines
3.6 KiB
Bash
Executable File

#!/usr/bin/env bash
# Build the GCC 16 cross-compiler (x86_64-linux -> x86_64-unknown-redox).
#
# Why this exists
# ---------------
# mk/prefix.mk has two toolchain paths:
# PREFIX_BINARY=1 (the default, mk/config.mk:13) downloads a prebuilt
# GCC 13.2.0 from static.redox-os.org.
# PREFIX_BINARY=0 cooks host:gcc13 through the cookbook.
# The second path is dead in this fork: it copies
# "$(GCC_TARGET)/stage.cxx/usr/" (mk/prefix.mk:315) and nothing in src/
# ever produces a stage.cxx directory, so it cannot have run. Repairing
# the cookbook's from-source path is a separate piece of work and is not
# required to obtain a newer GCC.
#
# This script therefore builds the cross compiler directly against the
# artifacts the prefix already provides: binutils 2.43.1 and the relibc
# sysroot (libc.a, crt*.o, headers). Configure flags mirror the cross arm
# of recipes/dev/gcc13/recipe.toml so the resulting compiler is
# configured like the one it replaces.
#
# The GCC 16 source must already carry the Redox target port:
# python3 local/patches/gcc-redox-port/apply-redox-port.py \
# local/recipes/dev/gcc16/source
# (then regenerate libstdc++-v3/configure with autoconf 2.69)
# See local/patches/gcc-redox-port/README.md.
set -euo pipefail
ROOT=$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)
TARGET=x86_64-unknown-redox
PREFIX_DIR="$ROOT/prefix/$TARGET"
SYSROOT="$PREFIX_DIR/sysroot/$TARGET"
SRC="$ROOT/local/recipes/dev/gcc16/source"
BUILD="$ROOT/build/gcc16-build"
INSTALL="$ROOT/build/gcc16-install"
JOBS="${JOBS:-$(nproc)}"
for req in "$SRC/gcc/BASE-VER" "$SYSROOT/lib/libc.a" "$PREFIX_DIR/gcc-install/bin/$TARGET-as"; do
[ -e "$req" ] || { echo "FATAL: missing prerequisite: $req" >&2; exit 1; }
done
# The port must be present, or we would silently build a compiler with no
# Redox target and only discover it at the end of a ~40 minute build.
grep -q 'redox' "$SRC/gcc/config.gcc" || {
echo "FATAL: $SRC is not Redox-ported (gcc/config.gcc has no redox arm)." >&2
echo " Run local/patches/gcc-redox-port/apply-redox-port.py first." >&2
exit 1
}
grep -q 'redox' "$SRC/libstdc++-v3/configure" || {
echo "FATAL: libstdc++-v3/configure has no redox arm -- it was not" >&2
echo " regenerated from the patched crossconfig.m4 (autoconf 2.69)." >&2
exit 1
}
echo "GCC version : $(cat "$SRC/gcc/BASE-VER")"
echo "target : $TARGET"
echo "sysroot : $SYSROOT"
echo "install : $INSTALL"
echo "jobs : $JOBS"
export PATH="$PREFIX_DIR/gcc-install/bin:$PATH"
# Redox has no SystemTap probes, but the configure probe can see the host's
# sys/sdt.h and then libgcc fails including a header the target lacks.
# Same reasoning as recipes/dev/gcc13/recipe.toml.
export gcc_cv_sys_sdt_h=no
rm -rf "$BUILD" "$INSTALL"
mkdir -p "$BUILD" "$INSTALL"
cd "$BUILD"
"$SRC/configure" \
--build=x86_64-pc-linux-gnu \
--host=x86_64-pc-linux-gnu \
--target="$TARGET" \
--prefix="$INSTALL" \
--with-sysroot="$SYSROOT" \
--with-native-system-header-dir="/include" \
--with-linker-hash-style=gnu \
--enable-languages=c,c++,lto \
--enable-initfini-array \
--enable-threads=posix \
--enable-libstdcxx-threads \
--enable-frame-pointer \
--disable-nls \
--disable-multilib \
--disable-bootstrap \
--with-bugurl="https://gitea.redbearos.org/vasilito/RedBear-OS/-/issues"
"${MAKE:-make}" -j "$JOBS" all-gcc
"${MAKE:-make}" -j "$JOBS" all-target-libgcc
"${MAKE:-make}" -j "$JOBS" all-target-libstdc++-v3
"${MAKE:-make}" install-gcc install-target-libgcc install-target-libstdc++-v3
echo
echo "BUILD OK"
"$INSTALL/bin/$TARGET-gcc" --version | head -1