The patch was written against git 2.13.1 (2017) while the recipe fetches
2.55.0 — eight years of drift, seven of eight files rejecting. Rebased by
applying what still fit, hand-porting every reject against the current
source, and regenerating the whole patch from a pristine-vs-ported diff so
it is a coherent 2.55.0 patch rather than a 2.13 patch with fixups.
Per file, preserving the original Redox intent:
compat/bswap.h <machine/endian.h> for ntohl/htonl
compat/terminal.c __redox__ git_terminal_prompt branch; the file was
restructured, so it now precedes the generic #else
configure NO_IPV6=YesPlease
daemon.c logreport is a switch over LOG_DESTINATION_* in
2.55.0; guard the syslog arm and openlog instead of
the old if/else
git-compat-util.h SIG_DFL/SIG_IGN/SIG_ERR fallbacks
Makefile EXTLIBS=-lnghttp2; drop the three hardlink fallbacks
run-command.c dup_devnull is gone in 2.55.0; the four /dev/null
opens it replaced now use DEV_NULL directly
setup.c sanitize_stdfds uses xopen/xdup, which die
internally, so the old die_errno hunk is obsolete
Applies at --fuzz=0 with zero rejects across all eight files.
Also ac_cv_iconv_omits_bom=no: the 'iconv omits bom for utf-16 and
utf-32' probe is a RUN test and cannot execute while cross compiling.
Same mechanism as the neighbouring ac_cv_fread_reads_directories and
ac_cv_snprintf_returns_bogus entries.
One trap worth recording: a blanket '*.orig' cleanup before regenerating
the diff silently deleted t/t4256/1/mailinfo.c.orig, a real git test
fixture, which would have shipped as a deletion in the patch. Restored.
git.patch is written against git 2.13.1 (2017); the recipe fetches 2.55.0.
The setup.c hunks were the first to fail, so the build stopped there.
Rebased them. 2.55.0 rewrote sanitize_stdfds() to use xopen/xdup, which
die internally, so the old die_errno hunk is obsolete and the rebase is
smaller than the original:
- xopen("/dev/null", O_RDWR) -> xopen(DEV_NULL, O_RDWR)
- #if !defined(__redox__) around setsid()
Both preserve the original Redox intent: scheme paths instead of
/dev/null, and no setsid() on Redox.
This does NOT make git build. With setup.c applying, the patch runs
further and six more files turn out to have drifted over the same eight
years:
compat/bswap.h 1/1 hunk
compat/terminal.c 1/1
configure 1/1
daemon.c 2/4
git-compat-util.h 1/2
Makefile 1/1
run-command.c 1/1
git-compat-util.h matters most: it is where DEV_NULL is defined, so the
setup.c change above depends on that hunk being re-ported too.
An eight-year, 2.13 -> 2.55 span is a re-port, not a hunk rebase, and
PATCH-GOVERNANCE.md is explicit that the patch is rebased rather than
dropped. Committing this piece so it is not lost and the remaining scope
is written down.
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