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.
feature_summary aborted on two REQUIRED packages:
* X11 -- "Required for building the X11 based workspace". The libraries exist
(promoted out of wip and building), but plasma-desktop did not depend on
them, so they were absent from its sysroot and cmake reported X11 missing.
Exactly the gap libxcb had earlier. Added libx11, libxext, libxfixes, libxi,
libxrender, libxau, libxdmcp.
This is where providing the real X11 stack pays off: the alternative was
patching plasma-desktop to stop requiring X11 at all, which is a much larger
and more invasive change than declaring a dependency that already builds.
* KF6DocTools -- not ported, and REQUIRED only because BUILD_DOC defaults ON.
Disabled: this drops generated handbook pages, not functionality; every
settings module still builds.
kcms/touchpad/CMakeLists.txt:18 carries the identical FATAL_ERROR to
kcms/mouse, on the same missing xorg-libinput (the X SERVER input driver, not
portable to a system with no X server). Disabled pre-emptively rather than
after another ~15-minute cycle rediscovers it.
Both KCMs keep their KWin+Wayland backends -- BUILD_KCM_MOUSE_KWIN_WAYLAND and
BUILD_KCM_TOUCHPAD_KWIN_WAYLAND remain ON -- so neither module is lost, only
its unusable X11-session path.
kcms/mouse/CMakeLists.txt:4 gates an X11-specific backend on xorg-libinput,
X11_Xi and X11_Xinput, and aborts naming the remedy:
Missing X11 dependencies for kcm_mouse: xorg-libinput;X11_Xi;X11_Xinput.
Install dependencies or set CMake option -DBUILD_KCM_MOUSE_X11=OFF.
xorg-libinput is the X SERVER input driver -- there is no X server here, so it
is not a porting candidate. This drops only the X11-session backend; the mouse
KCM still builds with its Wayland/libinput backend, which is the one actually
used.
The single sed with an embedded \n had to survive TOML unescaping, then the
shell, then sed's insert parsing -- and it did not. The generated file began
with 'nclude(CheckIncludeFiles)', losing the leading 'i', so configure failed
with
ConfigureChecks.cmake:2 (nclude): Unknown CMake command
My earlier dry-run passed because I ran the sed by hand in the shell rather
than the form the recipe actually produces after parsing. Verified this time by
extracting the commands from the PARSED TOML and running those: the file now
starts with include(CheckFunctionExists) / include(CheckIncludeFiles).
ConfigureChecks.cmake calls check_function_exists() and check_include_files()
without including the modules that define them:
ConfigureChecks.cmake:14: Unknown CMake command "check_function_exists"
Upstream gets away with it because a native KDE configure has already pulled
those modules in transitively by that point; that does not happen here. CMake
documents both as requiring an explicit include(), so adding them is what
upstream should have done rather than a workaround.
ConfigureChecks.cmake:7 does
pkg_get_variable(XKBDIR xkeyboard-config xkb_base)
if (NOT EXISTS "${CMAKE_SYSROOT}/${XKBDIR}")
assuming pkg-config returns an unprefixed path. This build sets
PKG_CONFIG_SYSROOT_DIR, so pkg-config already applies the sysroot and XKBDIR
comes back absolute. Prefixing again produced
.../sysroot//mnt/data/.../sysroot/usr/share/X11/xkb
and configure aborted although the directory is present (verified: the xkb
directory IS in plasma-desktop's sysroot, and xkeyboard-config.pc correctly
records xkb_base=/usr/share/X11/xkb).
Accepts either form instead of un-prefixing XKBDIR: which one pkg-config
returns depends on PKG_CONFIG_SYSROOT_DIR, so testing both is correct in both
configurations and keeps the check meaningful rather than disabling it.
plasma-desktop requires it unconditionally:
CMakeLists.txt:244 pkg_check_modules(XKBREGISTRY xkbregistry REQUIRED ...)
and configure aborted with "The following required packages were not found:
- xkbregistry". The recipe had -Denable-xkbregistry=false.
xkbregistry provides the keyboard-layout registry the keyboard KCM reads, so
this restores a real feature rather than routing around one. Its dependency,
libxml2, was already in the tree (recipes/libs/libxml2) and is now declared and
added to the config.
-Denable-x11 is deliberately left false for now: it is a separate switch, not
required by this failure, and turning it on alongside would blur which change
fixed what if the rebuild misbehaves.
vasilito