New SCHEME COMPATIBILITY POLICY: upstream Redox schemes are frozen
contracts (paths, listing formats, semantics, error codes); Red Bear-only
schemes may be introduced but must never collide with upstream namespaces;
the 2026-08-05 cpu-NN regression is recorded as the canonical violation.
Kernel gitlink bump carries the {:02x} listing revert.
Operator decision 2026-08-05: "we will not have gcc 13." The cross
toolchain has been GCC 16.1.0 since the port landed, but the build system
still defaulted to GCC 13 in three places and nothing recorded the move.
Build system:
- mk/prefix.mk: GCC_RECIPE?=gcc13 -> gcc16.
- mk/prefix.mk: the HOSTED_REDOX package rule derives its names from
$(GCC_RECIPE) instead of hardcoding gcc13.pkgar / gcc13.cxx.pkgar.
static.redox-os.org publishes no gcc16 package, so that path now fails
at download. Deliberate: a loud failure beats a wrong compiler.
- build-redbear.sh: refuse to build on a non-GCC-16 toolchain. This is
the one that mattered on a Linux host. `make prefix` unpacks upstream's
gcc-install.tar.gz, which IS GCC 13.2.0, and no make rule replaces it --
GCC 16 arrives only via install-gcc16-toolchain.sh. A fresh prefix
therefore put you silently back on GCC 13, surfacing ~40 minutes later
as a kwin C++23 failure. The guard checks all three locations
(gcc-install, sysroot, ~/.redoxer/<target>/toolchain -- the last has
highest priority) and names the two scripts to run.
Docs:
- New local/docs/TOOLCHAIN-GCC16.md: why the move (kwin/plasma-workspace
need std::ranges::to), build/install/rollback procedure, the three
locations that must agree, the tree-wide -std=gnu17 and -fno-hardened
consequences, and the open libstdc++ float16-formatter gap that
currently blocks the kwin link.
- CHANGELOG, docs/README.md index and state summary, and the stale claim
in NATIVE-TOOLCHAIN-WORKSTREAM.md that gcc13 "still builds the GCC 13
cross toolchain".
Also corrects stale references found while auditing:
- AGENTS.md described prefix/ as "Clang/LLVM"; it is GCC 16.1.0 + LLVM + Rust.
- AGENTS.md cited local/reference/linux-7.0/ (tree is linux-7.1).
- AGENTS.md's durable-patching example cited a mesa patch that does not
exist; replaced with one wired in recipe.toml. (The first replacement
used patch 03, which the changelog records as orphaned -- it targets a
file removed from Mesa 26.1.4 upstream.)
native_bootstrap.sh still installs gcc13/gcc13.cxx packages inside a
Redox VM. Left alone: that is the deferred gcc-native workstream and no
gcc16 package is published for Redox to point it at.
Verified: bash -n clean; make -n prefix parses; guard accepts the current
16.1.0 toolchain in all three locations and rejects a stubbed 13.2.0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
l1_futex.rs uses AtomicU32::new and Ordering::SeqCst but imported neither, so
the crate did not compile:
error[E0433]: cannot find type `Ordering` in this scope (x4)
error[E0433]: cannot find type `AtomicU32` in this scope
Same class as the kernel errors fixed a moment ago: committed first-party code
that does not build, invisible while the package was served from cache. The
relibc bump invalidated the cache and both surfaced in the same run.
Verified: cook redbear-threadtest - successful.
The kernel had been served from cache for the whole session; a relibc bump
forced a real rebuild and exposed two committed type errors (madt/mod.rs
pattern against into_iter's owned tuples, and a usize/u64 comparison in
scheme/irq.rs). Neither was introduced here.
plasma-desktop compiled deep into its tree (105 packages cooked) and failed on
applets/taskmanager/backend.h:16: fatal error: netwm.h
because adding the X11 libraries made find_package(X11) succeed, so
CMakeLists.txt:211 set HAVE_X11=1 -- and the code then legitimately includes
KWindowSystem's X11-only headers, which our KWindowSystem does not install.
I tried the coherent fix first: KWINDOWSYSTEM_X11=ON. It fails because Qt here
is built without the xcb platform:
src/platforms/xcb/kxerrorhandler_p.h:15: fatal error: private/qtx11extras_p.h
That header ships only with Qt's X11 support, so enabling KWindowSystem X11
cascades into rebuilding qtbase with the entire xcb plugin stack. Too large to
start mid-build; reverted with the reason recorded at the flag.
So HAVE_X11=1 asserts "Qt/KDE X11 integration is available", which is false
here. Forced to 0 -- the honest value -- and the gating script compiles those
paths out. The X11 libraries remain, because they ARE required: X11 is TYPE
REQUIRED in plasma-desktop and libxcb is needed unconditionally.
Also promotes xcb-util-keysyms and xcb-util-wm (built and staged:
libxcb-keysyms.a, libxcb-icccm.a, libxcb-ewmh.a), which KWindowSystem X11 would
need and which are cheap to have available.
Pre-existing uncommitted first-party work, surfaced by the first-party
integrity gate. Committing rather than reverting: this code exists nowhere but
this project, so a revert would destroy it outright, and it is coherent and
self-consistent -- a DMI entry for the board plus a test in toml_loader.rs that
parses the REAL 50-system.toml and asserts the entry matches while LG entries
do not.
The quirk carries no flags by design; its comment states it is a bare-metal
anchor so future board-specific quirks can be added precisely. Related to the
Ryzen 7000 / X670E work in .omo/plans/ryzen-7000-x670e-compat.md.
Not authored in this session -- committed here because it blocked every build
and the gate's guidance is to commit or revert, and reverting irreplaceable
work is the wrong call.
plasma-desktop cleared configure and failed in the build:
/bin/sh: .../sysroot/lib/libexec/kf6/kconfig_compiler_kf6: cannot execute
KF6 exports these generators as imported targets whose IMPORTED_LOCATION is the
TARGET (Redox) binary in the sysroot, so cmake tries to run a Redox ELF on the
build host.
Overlays the HOST binary onto the path the imported target points at. Their
output is plain text/XML, so a host build is equivalent, and this keeps the
features ENABLED rather than switching them off. Same block plasma-workspace
already carries -- verified /usr/lib/kf6/kconfig_compiler_kf6 exists on this
host before relying on it.
kcms/keyboard links X11::xkbfile (CMakeLists.txt:37) and cmake aborted with
"Target kded_keyboard links to X11::xkbfile but the target was not found".
libxkbfile was sitting in recipes/wip/x11; promoted, given its util-macros
dependency, and wired into plasma-desktop and the config.
Also clears 9 build directories stranded by the earlier `git mv` out of wip.
Autotools bakes the absolute srcdir into its generated Makefiles, so a moved
recipe keeps building against a path that no longer exists:
No rule to make target
'.../recipes/wip/x11/libxkbfile/source/src/cout.c', needed by 'cout.lo'
The cook-side auto-invalidation added earlier only inspects CMakeCache.txt, so
autotools recipes are not covered by it -- these were latent failures that
would have surfaced one package at a time (libx11, libxcb, libxdmcp, libxft,
libxrender, x11proto, x11proto-kb, xcb-proto, xtrans).
Verified: cook libxkbfile - successful, libxkbfile.a staged.
vasilito