Three defects found and fixed, each verified to go to zero:
1. libcody C++ standard. Its configure contains
#if __cplusplus > 201103
#error "C++11 is required"
so anything newer than C++11 is rejected outright. My earlier
-std=gnu++17 tripped exactly this -- the 'C++11 is required' failure
came from build/libcody/config.log, not from a missing libstdc++ as
the previous commit assumed. C++11 also fixes the original problem:
char8_t arrived in C++20, so under C++11 u8"" is still const char[].
char8_t diagnostics: 100+ -> 0.
2. libcody is compiled by the CROSS compiler, not the host one --
x86_64-unknown-redox-g++ ... -c -o buffer.o .../libcody/buffer.cc
because --host is the Redox target. So plain CXXFLAGS is the right
knob, scoped to this branch; the freestanding branch must keep the
compiler defaults.
3. libgcc's cpuinfo.c needs CPUID bit macros from <cpuid.h>. Built by
GCC 16 that resolves to GCC 16's header, and GCC 15/16 REMOVED the
macros for the withdrawn AVX512PF/ER/4VNNIW/4FMAPS and PREFETCHWT1
extensions. GCC 13 ships its own cpuid.h that still defines them, so
its config dir now precedes the toolchain include path for target
compiles. Undeclared-bit errors: 5 -> 0.
BLOCKED, and not by a flag. GCC 16 now ICEs compiling GCC 13's own
libstdc++:
libstdc++-v3/libsupc++/eh_call.cc:39:1: internal compiler error:
in gimple_build_eh_must_not_throw
Each fix has revealed the next incompatibility; an ICE is where
flag-tweaking stops being the answer. Building GCC 13 with GCC 16 is
three major versions of drift and is not a supported configuration.
The coherent fix is to move gcc-native onto GCC 16, which is the whole
point of the port in local/patches/gcc-redox-port/ -- local/recipes/dev/
gcc16/source is already ported and is what produced the working cross
toolchain. That is an operator-level decision, so it is not taken here.
libcody is compiled by the CROSS compiler, not the host one -- the build
log shows
x86_64-unknown-redox-g++ ... -c -o buffer.o .../libcody/buffer.cc
because --host is the Redox target. So plain CXXFLAGS is the right knob,
not CXXFLAGS_FOR_BUILD as the previous commit assumed. Scoped to the
gcc-native branch only.
Verified: char8_t errors go 100+ -> 0.
STILL OPEN. With CXXFLAGS set, the top-level configure now fails its
build-side probe:
checking whether gcc accepts -g... no
configure: error: C++11 is required
The two states are exclusive as things stand:
- CXXFLAGS carrying -std=gnu++17 -> char8_t fixed, C++11 probe fails
- CXXFLAGS without it -> probe passes, char8_t fails
so something in the exported CXXFLAGS is unacceptable to the HOST gcc
that configure probes (the cookbook adds -fno-hardened -DHAVE_ALLOCA_H=1
-fPIC alongside a target -I). The recipe unsets CFLAGS/CPPFLAGS/LDFLAGS
for this branch but leaves CXXFLAGS set, which is the likely culprit --
the next step is to give the build-side compiler its own clean flags
rather than inheriting the target's.
local/sources/libc is libc 0.2.189 with src/unix/redox/mod.rs extended to
expose the waitid surface relibc already implements:
- idtype_t (= c_int, as relibc defines it)
- P_ALL / P_PID / P_PGID
- CLD_EXITED / KILLED / DUMPED / TRAPPED / STOPPED / CONTINUED
- extern fn waitid(idtype_t, id_t, *mut siginfo_t, c_int) -> c_int
All of it is real in relibc -- src/header/sys_wait/mod.rs defines the
types and constants, and `nm libc.a` shows `T waitid` -- but the libc
crate's Redox bindings never exposed any of it, and still do not as of
0.2.189. Any crate calling waitid therefore cannot build for
x86_64-unknown-redox:
error[E0531]: cannot find unit struct, unit variant or constant
`CLD_EXITED` in crate `libc`
which breaks nix, and through it ctrlc and rustc's bootstrap tooling --
the last thing blocking rust-native.
Values and types come from relibc, not from Linux. Every non-Redox target
is byte-for-byte upstream 0.2.189, so host builds are unaffected. Wired
into the rust workspace via [patch.crates-io]; the fork type-checks for
x86_64-unknown-redox.
Upstream-reportable: this gap belongs in the libc crate.
Putting it in plain CXXFLAGS also handed it to the Redox cross g++, whose
C++ probe then failed during the freestanding stage, before libstdc++
exists:
configure: error: C++11 is required
libcody -- where the char8_t failures occur -- is compiled by
CXX_FOR_BUILD (the host g++ 16), so CXXFLAGS_FOR_BUILD is the correct
knob and the cross compiler is left alone.
gcc13
The host compiler is now GCC 16, which defaults to C++20
(__cplusplus 202002L). C++20 changed u8"" literals from const char[] to
const char8_t[], and GCC 13's libcody -- its module mapper -- uses them
throughout, so the build collapsed with ~100 diagnostics like
error: invalid conversion from 'const char8_t*' to 'const char*'
in libcody/{buffer,client,server}.cc. GCC 13's sources are C++17; build
them at that standard. Not a workaround -- it is the dialect this
release was written against.
rust / rust-native
nix 0.30.1 is incompatible with the resolved libc 0.2.178: it declares
type SaFlags_t = libc::c_ulong while libc now has sigaction.sa_flags and
the SA_* constants as c_int, so rustc's bootstrap tooling failed with
error[E0308]: expected `u64`, found `i32` nix/src/macros.rs:72
error[E0308]: expected `i32`, found `u64` nix/src/sys/signal.rs:808
nix 0.31 fixed it by flipping the default to c_int. ctrlc moves itself
(3.5 requires nix "0.31"), but in-tree miri pinned 0.30.1 and kept the
broken version in the graph, so both are moved forward -- update and
adapt rather than pinning libc back, per the
Most-recent-upstream-when-building rule. Both crates were already in the
offline registry cache.
These surfaced only because gcc-native/rust-native were restored to the
config; neither had been building.
git links -lintl (libintl, from gettext) for i18n but never declared gettext as
a build dependency — it was implicitly relying on libintl.a already being in the
shared prefix sysroot from another package. When the relibc/kernel-touched boot-
ABI relink cleaned the sysroot, git's own sysroot lacked libintl and the link
failed. Declare the dependency so libintl.a is staged into git's sysroot.
A Redox cross build cannot run the target shader-precompile tools on the host,
so build them natively once and feed them to the cross Mesa via
-Dmesa-clc=system -Dprecomp-compiler=system. Native meson build against
llvm-native's CLEAN host LLVM/Clang (the redoxer toolchain's llvm-config emits
-I<toolchain>/include, which holds Redox target libc headers that poison host
g++), host system deps (libdrm/expat/zlib/zstd), and our host-built
SPIRV-Tools/LLVMSPIRVLib/libclc (pkg-config with absolute .pc prefixes; native
pkg-config, not the cross wrapper). Driver-agnostic tools, so iris-only (no
amdgpu-LLVM needed); they serve radeonsi/radv in the cross build too.
Mesa's radeonsi gallium driver requires libelf. Add a libelf recipe that builds
only the elfutils lib/+libelf/ subdirs (avoiding the libdw/libasm/tools glibc
surface) as a PIC static archive, relying on the new relibc headers/functions
(byteswap/error/libintl/ar/search + tsearch/mempcpy/rawmemchr). Installs
libelf.a + libelf.h/gelf.h/nlist.h + libelf.pc. Wired into mesa deps.
Verified: cook libelf - successful.
The host libLLVM.so (COOKBOOK_HOST_SYSROOT=/usr branch) lives in the redoxer
toolchain and is dynamically linked by rustc's librustc_driver. Building it as
X86;AMDGPU;NVPTX only dropped AArch64/RISCV, so after the AMDGPU splice rustc
failed to load with 'undefined symbol: LLVMInitializeAArch64AsmPrinter' —
breaking every Rust compile in the tree. Build the host LLVM with all CPU
targets rustc emits (X86;AArch64;RISCV) PLUS the GPU backends (AMDGPU;NVPTX).
The Redox-target llvm21 stays X86;AMDGPU;NVPTX (Redox is amd64-only, no need to
bloat the shipped libLLVM with foreign CPU backends).
Fixes a latent regression from 80d20db8/a6999912.
Shipping the Intel iris/ANV gallium+vulkan drivers turns on Mesa's with_clc
(with_driver_using_cl), which requires, in the native mesa_clc/intel_clc shader
precompile path: LLVMSPIRVLib (SPIRV-LLVM-Translator), SPIRV-Tools, and clang's
C++ libraries. None had recipes. Add three host-built dev recipes modelled on
libclc (built against llvm-native's host LLVM 21, staged into the cross sysroot
so Mesa's pkg-config resolves them):
- spirv-headers (SPIR-V grammar + headers; find_package package)
- spirv-tools (SPIRV-Tools.pc; SPIRV-Headers via find_package)
- spirv-llvm-translator (LLVMSPIRVLib.pc, v21.1.0.0; llvm_release_210 branch)
All three clear the cross-sysroot __libc_start_main leak with the llvm21-style
flag-clearing block in their native toolchain files.
Wire them + clang21 into mesa deps: Mesa resolves dep_clang via
cpp.find_library('clang-cpp', dirs: llvm-config --libdir), which the wrapper
rewrites to the target sysroot/lib, so clang21's target libclang-cpp.so must be
staged there (shared-llvm=enabled avoids needing the static clang libs).
Verified: mesa meson now passes amdgpu, LLVMSPIRVLib, SPIRV-Tools, and clang-cpp
(next gate is libelf for radeonsi).
Per operator: don't forget Intel + virgl, and prepare for future NVIDIA. Intel
(iris/anvil) and virgl need NO LLVM GPU backend (NIR / virtualized) — they stay
in Mesa's driver lists as first-class targets. AMD needs AMDGPU (now); NVIDIA
(future, nouveau/NVK) needs NVPTX. LLVM rebuilds are very expensive, so include
NVPTX now (llvm21: X86;AMDGPU;NVPTX) to avoid an LLVM rebuild when NVIDIA lands.
Documented the vendor->driver->LLVM-backend matrix in the amd64-only policy.
Mesa's radeonsi/radv AMD-GPU drivers require the LLVM 'amdgpu' codegen backend
(dependency('llvm', modules: [... amdgpu ...])). llvm21 built X86 only, so the
host llvm-config the mesa build reads reported amdgpu(missing). Add AMDGPU to
LLVM_TARGETS_TO_BUILD (X86;AMDGPU per the amd64-only policy — AMDGPU is a GPU
backend, not a second CPU platform). This is the redox-target LLVM whose libs
mesa links AND the source of the prefix clang-install host LLVM. NB: the
~/.redoxer toolchain host llvm-config (a provisioned prebuilt) still needs the
rebuilt AMDGPU host-LLVM propagated into it (follow-up).
Cross-building lld/llvm needs a HOST-runnable llvm-tblgen to generate the
Options.inc opt-parser sources, and it must match the LLVM 21 source tree.
Both recipes referenced ${COOKBOOK_HOST_SYSROOT}/bin/llvm-tblgen, but the
cookbook does not export COOKBOOK_HOST_SYSROOT, so the path collapsed to the
host /bin/llvm-tblgen. On a rolling distro that is now LLVM 22, whose
-gen-opt-parser-defs backend requires a 'SubCommand' TableGen class absent
from LLVM 21's OptParser.td:
error: The class 'SubCommand' is not defined
Default COOKBOOK_HOST_SYSROOT to the redoxer toolchain (host-runnable LLVM
21.1.2 llvm-/clang-tblgen), exactly as the sibling clang21 recipe already
does. Fixes the full-target build reaching mesa's LLVM build-deps.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
clang21 (recipes/dev/clang21): the cross build (redox target) references
${COOKBOOK_HOST_SYSROOT}/bin/clang-tblgen and .../llvm-tblgen to generate the
*.inc sources, but cookbook does not export COOKBOOK_HOST_SYSROOT, so the paths
collapsed to /bin/clang-tblgen and ninja died: "'/bin/clang-tblgen' ... missing
and no known rule to make it". Point COOKBOOK_HOST_SYSROOT at the redoxer
toolchain, which ships host-runnable clang-tblgen/llvm-tblgen (LLVM 21.1.2) —
the same way the mesa recipe sets it.
libxml2 (recipes/libs/libxml2): declare the libiconv dependency. libxml2 2.15.x
requires iconv and its configure aborts "libiconv not found"; a libiconv recipe
exists but was never built because nothing depended on it.
Both are base recipes (not the operator's dirty mesa/kf6/libclc source WIP).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
libclc was vendored at recipes/dev/llvm21/source/libclc/ as a
build artifact of the llvm21 fork. This promoted it from an
implicit Mesa dependency (the CLC bitcode Mesa consumes) to a
first-class local project, mirroring how tlc, redbear-*, cub, etc.
are organized per local/AGENTS.md.
Local layout follows the existing in-house pattern:
recipes/dev/libclc -> ../../local/recipes/dev/libclc
local/recipes/dev/libclc/recipe.toml
local/recipes/dev/libclc/source/ (vendored from llvm-project)
The recipe builds libclc as a host-side CMake project using the
cookbook-sysroot clang21 binary (not the cross-compiler) to compile
OpenCL kernels to .bc bitcode. Output targets are amdgcn, amdgcn-amdhsa,
r600, generic, and spirv — the union that Mesa's clc tool consumes
for the iris/radeonsi/llvmpipe drivers. ptx-nvidiacl and clspv are
excluded because they don't map onto any Mesa hardware driver.
The recipe also wires the cookbook's native-cmake generation with
an override that points CMAKE_C_COMPILER etc. at the cookbook
sysroot's clang-21 binary. This is needed because libclc must
run on the build host (output is bitcode, not a Redox binary),
and the cookbook's default cross-toolchain would link the build
against relibc instead of host glibc.
libclc.pc is installed at usr/lib/pkgconfig/, satisfying Mesa's
dependency('libclc') lookup. The .bc files are installed under
usr/share/clc/, which is what the libclc.pc libexecdir pointer
(libexecdir=<prefix>/share/clc) expects.
This is the prerequisite for re-enabling iris, radeonsi, and the
Intel Vulkan driver in the Mesa recipe (Phase 4-6 of
local/docs/3D-DRIVER-PLAN.md). With libclc available in the
cross-sysroot, mesa's meson '-Dwith_clc -> dependency(libclc)'
resolves and the gallium drivers compile.
recipes/dev/gcc13 was claiming name='cxx' — conflicted with
local/recipes/dev/gcc-native also claiming 'cxx'. Renamed to match
directory names for unique package identification by the cookbook.
Comprehensive fix — not a fallback. Each recipe now has explicit
[package] section with name and version. Version inference:
- Git-source recipes without rev/branch: '0.1.0' (Red Bear convention)
- Tar/git recipes with version in URL or dir name: extracted version
- Sysroot-copy recipes: matched to toolchain version
Affected: 250+ recipes across all categories (core, libs, dev, system,
kde, qt, drivers, gpu, drm, kernel, userspace, etc.) Every recipe
in the redbear-mini build chain that was missing [package] now has
explicit version metadata. Cookbook can now always determine a version
at packaging time, eliminating 'cannot guess version' failures.
No cookbook fallback hack — the source of truth is recipe metadata.
Phase 4.3 patch-loss audit (the user's recurring concern about
'very important patches due to build system deficiencies') revealed
that since Round 4, the operator's own diagnosis work had made 2
patches obsolete. Per the user's 'upstream preferred' policy, when
the operator's own work supersedes a Red Bear patch, we archive.
P0-canary (operator-superseded):
- Original: Phase 1.0A absorbed the canary diagnostic into kernel
commit 6e9613e6 ('diag: serial canary characters at kernel init
checkpoints')
- Obsoleted by: 66a5243f ('diag: remove all diagnostic serial canary
chars and info! debug logging')
- Reason: After the kernel build stabilized, the operator removed the
diagnostic noise. The canary's purpose (early-boot serial output)
is no longer needed.
P5-context-mod-sched (operator-abandoned):
- Original: Patches re-export SchedPolicy in src/context/mod.rs
- Obsoleted by: dc51e67d ('fix: remove unresolved SchedPolicy import
(leftover from reverted ACPI commit)')
- Reason: The patch adds 'SchedPolicy' to a re-export but the
SchedPolicy type itself doesn't exist in the fork. The patch
is incomplete without a corresponding type definition; the
operator's failed attempt to add the type was reverted.
Both moves follow AGENTS.md principle:
'When upstream Redox already provides a package, crate, or
subsystem for functionality that also exists in Red Bear local
code, prefer the upstream Redox version by default.'
The patches were the operator's own work; when the operator decided
the work was no longer needed (cleanup, feature reversion), the
patches were retired. 'Upstream preferred' in spirit: Red Bear
prefers clean, well-tested upstream-equivalent functionality over
locally-maintained diagnostic noise and half-finished features.
After this commit:
Active patches: 119 (was 121)
Archived: 96 in legacy-superseded-2026-07-12/
All forks: 0 orphans
iPerf3 3.21 is a bug fix release from July 2025.
rsync 3.4.4 is the latest 3.4.x maintenance release.
git 2.55.0 is the latest 2.55.x stable release, fixing 9+ years of CVEs
and bugs since the Red Bear build's 2.13.1 baseline. This is a security
critical upgrade.
Live upstream versions verified 2026-07-11:
- gnu-grep 3.12 (2025-04-10) -- https://ftp.gnu.org/gnu/grep/
- libsodium 1.0.22-stable (2026-07-08) -- https://download.libsodium.org/libsodium/releases/
- autoconf 2.73 (2026-03-20) -- https://ftp.gnu.org/gnu/autoconf/
Each recipe updated with new tar URL + BLAKE3 hash. Build-tool upgrades are
isolated from the fork content-verification system, so these are SAFE to
upgrade without the relibc-style risk.
diffutils was already at 3.12 (previously committed).
Also: fork-upstream-map.toml — bootloader flagged PENDING_REBASE
(2026-07-11 detection: 1.0.0 tag mismatch, fork based on 0.1.0 archive
not a true rebase — documented inline).
python312: Added --disable-test-modules to host build configure flags.
The host build (needed as dev-dependency for cross-compile) was
trying to compile test modules (_testmultiphase, xxlimited, etc.)
which fail on this system. The cross-compile already had this flag.
icu: Added --disable-tools to cross-compile configure flags. The ICU
data tools (genrb, derb) try to link against cross-compiled static
libraries, causing C++ vtable linker errors (undefined reference
to vtable for UTF16CollationIterator). Tools are built in the host
step; cross-compile only needs the libraries.
Combined with zsh --srcdir, base staging mkdir, and netstack fix,
these unblock the redbear-mini build.
- recipes/dev/python312/recipe.toml: use COOKBOOK_TOOLCHAIN for
--with-build-python instead of /tmp/python312, which the build system
never stages. Add [ -x ] guard for clear failure on missing dev-dep.
- recipes/core/userutils/recipe.toml: switch from upstream git URL to
local fork (local/sources/userutils/) per the local fork model. The
upstream source opens /scheme/pty/ptmx which the ptyd scheme does not
recognize; the local fork opens /scheme/pty correctly and avoids the
getty PTY panic.
- local/scripts/build-preflight.sh: warn when a recipe build script
references /tmp/<known-package>/, since the cookbook does not stage
host dev-deps under /tmp/<name>. Points authors at COOKBOOK_TOOLCHAIN.
- local/scripts/build-redbear.sh: replace 'tail -1 || true' on pre-cook
failures with proper error capture, last-50-lines tail on failure, and
exit-1. Verify the pkgar exists after a successful cook.
- Add x11proto to redbear-full.toml package list
- libxau recipe updated with x11proto dependency and custom build script
- Fixes libxau build failure: 'Package xproto was not found'
Derivative of Redox OS (https://www.redox-os.org) adding:
- AMD GPU driver (amdgpu) via LinuxKPI compat layer
- ext4 filesystem support (ext4d scheme daemon)
- ACPI fixes for AMD bare metal (x2APIC, DMAR, IVRS, MCFG)
- Custom branding (hostname, os-release, boot identity)
Build system is full upstream Redox with RBOS overlay in local/.
Patches for kernel, base, and relibc are symlinked from local/patches/
and protected from make clean/distclean. Custom recipes live in
local/recipes/ with symlinks into the recipes/ search path.
Build: make all CONFIG_NAME=redbear-full
Sync: ./local/scripts/sync-upstream.sh
vasilito