Three defects. gcc-native now cooks and publishes both packages.
1. Generator links failed with `undefined reference to __letf2@GCC_4.3.0`
(+ __gttf2 __eqtf2 __getf2 __unordtf2). The Redox libgcc_s.so.1 sits in
build/gcc/, and the host g++ resolves its libstdc++'s ld script
"GROUP ( libgcc_s.so.1 -lgcc )" against the cwd first, binding the REDOX
libgcc, which carries no GCC_4.3.0 soft-float symbols.
The recipe already defined _rb_linker_for_build for exactly this and never
passed it to make -- dead code. BUILD_LDFLAGS and BUILD_CPPFLAGS do not
exist in the TOP-LEVEL Makefile (they are gcc/Makefile variables), so a
top-level `make BUILD_LDFLAGS=...` never reaches the gcc sub-make.
CXX_FOR_BUILD does: the top level defines it and forwards it to every
sub-make, and gcc/Makefile.in:870 sets LINKER_FOR_BUILD = $(CXX_FOR_BUILD).
Confirmed with `make -n all-gcc` before changing anything.
The in-recipe note claiming LINKER_FOR_BUILD was tried and did not reach is
superseded: it reaches from inside build/gcc; the problem was propagation
from the top level.
Sequencing all-gcc first does NOT remove the cause, contrary to the older
comment -- it only holds for a clean build. This failure hit during all-gcc
before any target library was rebuilt, because a previous run had already
left libgcc_s.so.1 behind. Recipes must rebuild correctly on a dirty
target/, so the flag is the fix; sequencing stays as defence in depth.
2. Both C++23 modules were silently dropped. src/c++23/Makefile retries with an
EMPTIED std.cc when the compile fails, so the build exited 0 having shipped
no std.gcm or std.compat.gcm, with 41 'fenv_t has not been declared' errors
in the log.
#include_next <fenv.h> from the new libstdc++ wrapper resolved to the PREFIX
toolchain's installed copy of the same wrapper, guarded by the same
_GLIBCXX_FENV_H the new one had already defined -- so its body was skipped,
relibc's <fenv.h> was never reached, and every `using ::` below failed.
relibc is not at fault: the header compiles cleanly in C and C++ on its own.
Stock GCC builds target libraries with the in-tree compiler, which carries
-nostdinc++. Here CXX is the prefix compiler, so CXX_FOR_TARGET is plain and
the installed C++ headers stay on the search path. Fixed with
CXXFLAGS_FOR_TARGET, a top-level variable that reaches std.lo through
LTCXXCOMPILE, set before configure so the generated Makefiles carry it.
Verified: 41 errors -> 0, both "Cannot compile ... module" lines gone,
std.gcm and std.compat.gcm produced, std.cc/std.compat.cc 4502/795 lines
rather than emptied, libstdc++.modules.json staged.
Shipping this as an accepted limitation would have been a STUB AND
WORKAROUND POLICY violation regardless of GCC's Makefile being what empties
the source.
3. Changing CXX_FOR_BUILD makes autoconf refuse against an existing build dir
("`CXX' has changed since the previous run" in build-*/libcpp), since the
top level exports it as CXX into the build-side configure environment. That
is autoconf working correctly; documented, with the clean-build requirement.
Also records the subdirectories configure declines to build in this Canadian
cross (libatomic, libgomp, libsanitizer, libbacktrace among them) as an open
capability gap needing an operator decision, rather than leaving it unstated.
Carries earlier uncommitted working-tree changes to this recipe that the build
depends on (the CPPFLAGS sysroot strip, BUILD_CPPFLAGS restatement, static
libstdc++ staging, and the GCC 16 move).
Root cause: relibc Cond::wake() lost-wakeup race condition.
Fix: cur.load() instead of prev.load() in cond.rs wake().
The Remlab futex-condvar design assumes the caller holds the mutex when
signalling, but POSIX allows signalling outside the mutex and Rust
Condvar::notify_one does not require it. When signalling outside the
mutex, the waker reads prev before a concurrent waiter stores it,
producing cur=prev+1 that matches the value the waiter waits on:
lost wakeup, permanent hang, std::thread::scope blocks forever.
Guidance flipped from PENDING-EVIDENCE to FIX-APPLIED in
PACKAGE-BUILD-QUIRKS.md with validation matrix. Evidence file
updated with root cause trace and operator verification steps.
Fix commit: submodule/relibc @ c5806663
ISO rebuilt: build/x86_64/redbear-mini.iso (2026-08-05)
Host tests: 24/24 PASS
recipes/.gitignore ignores *.patch, so the symlink created alongside
patch 03 was left untracked while 01 and 02 are tracked (force-added
past the same rule). A clean checkout would fetch rust, find
patches = [... "03-generate-copyright-path-deps.patch"] in recipe.toml,
and fail to resolve it.
Force-added to match 01/02.
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.
vasilito