rust-native now builds. Records the three defects found getting there
(host/target header leak, the -fno-hardened cross-flag leak, relibc's
duplicate _POSIX_THREADS) and closes the previously-open "unreachable
'pub' item" item, which deny-warnings = false already resolved.
Corrects the gcc-native diagnosis. It read "the host's libstdc++ headers
are being pulled into a target compile"; the direction is the reverse --
relibc's TARGET headers reach a HOST compile through the redoxer
toolchain's mixed include/ directory, so __GLIBC_PREREQ is undefined
where the host headers expect it. That matters for how gcc-native gets
unblocked: the host: package pattern used for rust-native should apply,
rather than reworking GCC's cross-build header model.
Status flipped DEFERRED -> ACTIVE per the 2026-08-05 operator decision.
rust-native failed with ~200 errors inside the HOST's own glibc and
libstdc++ headers while compiling rustc_llvm's llvm-wrapper/*.cpp for
x86_64-unknown-linux-gnu.
rustc_llvm's build script passes `llvm-config --includedir` straight to
the host c++. The redoxer toolchain's include/ is a MIXED directory,
holding relibc's TARGET headers (stdlib.h, features.h, fenv.h, ...)
beside the llvm/ and clang/ ones, so relibc's features.h shadowed
glibc's, __GLIBC_PREREQ was never defined, and every host header testing
it failed:
/usr/include/c++/16/x86_64-pc-linux-gnu/bits/os_defines.h:44:19:
error: missing binary operator before token '('
Reproducible in three lines with no rustc involved:
printf '#include <cstdlib>\nint main(){}' > t.cpp
c++ -std=c++17 -I${HOME}/.redoxer/x86_64-unknown-redox/toolchain/include -c t.cpp
This is the same leak recorded as gcc-native's stopping point in
local/docs/NATIVE-TOOLCHAIN-WORKSTREAM.md -- one root cause, both
recipes -- though in the opposite direction to what that note assumed:
target headers reaching a host compile, not the reverse.
Fixed with host:llvm-native (+ .dev/.runtime). Host deps stage into
COOKBOOK_TOOLCHAIN, a tree SEPARATE from the target sysroot, so the
GNU/Linux libLLVM.so.21.1 cannot collide with the Redox one llvm21
stages -- the collision this recipe's llvm21 comment already records.
Its include tree holds only llvm/, llvm-c/, clang/, clang-c/, lld/. An
unset COOKBOOK_TOOLCHAIN is now a hard error rather than a silent
fallback to the polluted path.
Second defect, exposed by the first fix: DYNAMIC_INIT exports
CXXFLAGS=-fno-hardened for the GCC 16 cross compiler, and the unset list
dropped CC/CXX/LDFLAGS but not CFLAGS/CXXFLAGS/CPPFLAGS. cc-rs falls
back to the generic CXXFLAGS when the target-specific one is empty and
handed it to the host c++, which now resolves through
COOKBOOK_TOOLCHAIN/bin to llvm-native's clang++:
rustc_llvm@0.0.0: c++: error: unknown argument: '-fno-hardened'
A pre-existing leak: the cross recipes/dev/rust carries the same unset
list and never hit it only because nothing puts a clang on its PATH.
llvm-native's own recipe already unsets these three for this reason.
Target-side compilation is unaffected: config.toml pins cc/cxx/ar/linker
for the Redox triple, and the target RUSTFLAGS are captured into
CARGO_TARGET_<ARCH>_UNKNOWN_REDOX_RUSTFLAGS before the unset.
Also carries earlier uncommitted working-tree changes to this recipe
that the build depends on: the explicit relibc dependency, the
llvm-native -> llvm21 switch for the Redox-hosted rustc, and the
COOKBOOK_HOST_SYSROOT assignment, plus deny-warnings = false in
config.toml.
Verified: rustc, cargo, rustdoc, rustfmt, clippy-driver and
librustc_driver-*.so stage as Redox binaries -- ELF interpreter
/lib/ld64.so.1, OS/ABI System V, NEEDED libc.so.6 from relibc.
generate-copyright builds COPYRIGHT.html by reading each dependency's
licence files out of the bootstrap vendor directory. In-tree crates are
filtered out earlier (reuse covers them), so everything reaching
load_important_files is assumed to have been vendored.
cargo vendor only vendors REGISTRY sources. The libc fork arrives as a
[patch.crates-io] PATH dependency (02-libc-redox-fork.patch) living at
local/sources/libc, outside the rust tree -- neither in-tree nor
vendored. Joining the vendor root produced a directory that does not
exist, and read_dir failed the whole install step with a bare
Error: I/O Error: Os { code: 2, kind: NotFound }
naming no crate and no path, after the compiler had already built.
A path dependency's licence files live beside its own Cargo.toml, and
for such a crate that directory is the source of truth -- our fork ships
LICENSE-APACHE and LICENSE-MIT there. Falling back to the manifest
directory keeps those notices IN COPYRIGHT.html rather than dropping
them, which matters under the free/libre software policy in
local/AGENTS.md. Suppressing the step would have lost them.
The manifest directory is threaded from get_metadata (which holds the
full cargo_metadata::Package) to load_important_files and dropped again,
so get_metadata_and_notices keeps its existing public return type.
Patch ordering: 03 must follow 02, which introduces the path dependency
that makes it necessary.
Upstream-reportable: any downstream using [patch.crates-io] with a path
source hits this.
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.
vasilito