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.
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).
Install used an ABSOLUTE CMAKE_INSTALL_PREFIX (${COOKBOOK_STAGE}/usr) together
with DESTDIR=${COOKBOOK_STAGE}/stage, so everything double-nested under
stage.tmp/<abs>/stage.tmp/usr/... and libclc.pc/.bc never reached the expected
paths. Use the standard pattern: relative prefix /usr + DESTDIR=${COOKBOOK_STAGE}
(libclc.pc gets prefix=/usr, resolved downstream via PKG_CONFIG_SYSROOT_DIR);
drop the stage-flatten hack. Also relocate libclc.pc from share/pkgconfig
(upstream's DATADIR) to lib/pkgconfig (cookbook convention mesa looks up).
All 2610 GPU bitcode files already generate + install correctly.
In LIBCLC_STANDALONE_BUILD the bitcode-gen custom commands invoke the host tool
by bare name ('prepare_builtins -o foo.bc'), which fails 'command not found'
when '.' isn't in PATH. prepare_builtins is built into the build dir (CWD), so
add it to PATH before the ninja run.
CMAKE_CXX_COMPILER was the plain `clang` (C) driver, so cmake's link of the
C++ prepare_builtins tool did not pull in the C++ runtime -> ld failed
'libstdc++.so.6: DSO missing from command line' (undefined
std::__cxx11::basic_string::_M_assign). Resolve a HOST_CLANGXX (clang++) and
use it for CMAKE_CXX_COMPILER; clang++ links libstdc++. Verified: relinking
prepare-builtins.cpp.o with clang++ succeeds.
Moving llvm-native fully to dev-dependencies removed it from the cook set: the
cookbook's cook-tree (src/cook/tree.rs) only follows `dependencies` when
resolving --with-package-deps, so llvm-native was staged-but-never-built and
libclc failed installing a nonexistent stage.pkgar. Cooking llvm-native (main)
via `dependencies` produces all its subpackage pkgars; stage .dev + .runtime
(host static libs/cmake + host clang) as dev-dependencies.
LLVM_DEFAULT_TARGET_TRIPLE was ${TARGET} (redox), so the host clang defaulted
to x86_64-unknown-redox and searched the Redox sysroot for the C++ stdlib when
libclc compiled its host prepare_builtins.cpp -> 'type_traits' file not found.
A host clang must default to the host triple (the redoxer toolchain's clang
does exactly this: Target x86_64-unknown-linux-gnu). Set it to
${COOKBOOK_HOST_TARGET}. libclc's .cl->bitcode compiles pass -target amdgcn
explicitly, so the host default does not affect them.
The host build works and staged llvm-native's .dev (static libs + cmake) so
find_package(LLVM) now resolves — but the host clang binaries live in
llvm-native's .runtime subpackage, which libclc didn't pull. The .dev ->
.runtime package link does NOT transitively stage at build time, so libclc
errored 'host clang not found under .../sysroot/usr/bin'.
Move the entire host toolchain to dev-dependencies (build-only; libclc's
shipped artifact is the .bc/.pc files, never clang) and add llvm-native.runtime
explicitly so usr/bin/clang* is staged.
llvm-native's job is to supply a COMPLETE host LLVM dev tree (host clang +
host static component libs + matching cmake/llvm export) that libclc's
find_package(LLVM) and host clang need for Mesa's iris/radeonsi CLC path. The
redoxer toolchain ships host clang + libLLVM.so but strips the static libs, so
find_package fails — and stubbing them violates the no-stub policy.
The recipe was WRONGLY cross-compiling LLVM for the Redox target via
cookbook_cmake: that (a) produces host-unusable Redox binaries and (b) fails to
link because Redox's libstdc++ lacks symbols LLVM uses (std::random_device
etc.). My earlier LLVM_USE_HOST_TOOLS=OFF / tblgen-var / native.cmake patches
were all treating symptoms of that wrong architecture.
Rewrite: build entirely with the host gcc, targeting the host, exactly like
libclc builds its own host prepare_builtins tool — invoke cmake directly (not
cookbook_cmake) with /usr/bin/gcc and no CMAKE_SYSTEM_NAME so CROSSCOMPILING is
false (LLVM builds one native tblgen with host gcc; no NATIVE sub-project, no
Redox-header leak). Drop all Redox build-deps and the llvm21.runtime package
dep. Validated: host GCC 16.1.1 configures LLVM 21 and builds llvm-min-tblgen +
libLLVMSupport.a/libLLVMTableGen.a cleanly.
This is how upstream-style host LLVM tooling should be produced; it supersedes
the cross-build patch chain (312659fe21, 5d426d89a7, 872935057c, b2d9a31a4f).
Even with LLVM_TABLEGEN/CLANG_TABLEGEN provided, LLVM_USE_HOST_TOOLS defaults
ON when cross-compiling, so llvm/CMakeLists.txt creates the NATIVE external
project (llvm_create_cross_target LLVM NATIVE) — a full second HOST LLVM build
that inherits the Redox cross flags and died compiling native llvm-config.
We already supply the only native tools a cross-build needs (the tablegens),
so OFF eliminates the native sub-build entirely; LLVM uses the provided host
tblgens for .inc generation. Completes the llvm-native cross-build fix chain
(native-link, OPTIMIZED_TABLEGEN, LLVM_TABLEGEN var name, and now this).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Root cause of the native sub-build failure. A from-scratch LLVM build reads
the cache vars LLVM_TABLEGEN / CLANG_TABLEGEN to skip building a native
tblgen when cross-compiling (llvm/cmake/modules/TableGen.cmake: "Native
TableGen executable. Saves building one when cross-compiling"). The recipe
passed *_TABLEGEN_EXE, which that path does NOT read, so LLVM built its own
native tblgen via the CROSS_TOOLCHAIN_FLAGS_NATIVE sub-build. That native
build ran host gcc against Redox relibc headers (leaked via CMAKE_CXX_FLAGS)
and died on host/redox <stdlib.h> conflicts: __deprecated/__noreturn not a
type, duplicate div_t/ldiv_t. Passing the correct var names makes LLVM use the
redoxer toolchain's host tblgens (LLVM 21.1.2) and skip the native build.
lld21/clang21 build against a PREBUILT llvm and resolve tblgen via
find_program on their own LLVM_TABLEGEN_EXE cache var, so they stay correct.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two fixes for the native tblgen sub-build failing on <shared_mutex>:
- LLVM_OPTIMIZED_TABLEGEN=Off: this recipe already provides a host-runnable,
version-matched llvm-/clang-tblgen (redoxer toolchain, LLVM 21.1.2) via
*_TABLEGEN_EXE. OPTIMIZED_TABLEGEN=On ignored those and forced a redundant
native sub-build (CROSS_TOOLCHAIN_FLAGS_NATIVE) that failed. Off => LLVM uses
the provided tblgen and skips the native build. (llvm21 provides no tblgen,
so it keeps On and builds its own — different case, left as-is.)
- CMAKE_CXX_FLAGS --std=gnu++11 -> gnu++17: LLVM 21 requires C++17; the stale
gnu++11 could win the flag-order race in any sub-build and break the headers.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The native tablegen/tools sub-build (CROSS_TOOLCHAIN_FLAGS_NATIVE) generated
native.cmake against $COOKBOOK_TOOLCHAIN (the Redox cross sysroot) and never
cleared the inherited cross CMAKE_*_FLAGS, so the host try_compile linked
relibc and died with 'undefined reference to __libc_start_main'. Port llvm21's
proven fix: save+unset LDFLAGS/CFLAGS/CXXFLAGS, generate native.cmake against
/usr, CACHE FORCE-clear the cross flags for the native sub-cache, and restore
the cross flags via -DCMAKE_*_FLAGS (not the environment) for the cross build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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>
libclc's native build needs a COMPLETE host LLVM dev tree (host clang +
llvm-as/opt/llc/llvm-link + LLVMConfig/LLVMExports.cmake + the static
component libs they reference). The redoxer runtime toolchain ships only
libLLVM.so + clang, so find_package(LLVM) failed on missing static libs;
the cross llvm21.dev is the wrong (Redox-targeted) LLVM.
- deps: clang21/llvm21(+.dev) -> llvm-native(+.dev). Using ONLY llvm-native
avoids staging two conflicting usr/lib/cmake/llvm trees (host vs cross)
into the same sysroot path.
- script: resolve HOST_LLVM_PREFIX=$COOKBOOK_SYSROOT/usr; point
CMAKE_C/CXX/ASM_COMPILER + AR/NM/RANLIB at llvm-native's host binaries and
LLVM_DIR at its host cmake tree; add staged-file guards with diagnostics.
Unblocks the FULL graphics stack (mesa->qt->kf6->sddm). Cook-validated when
FULL reaches libclc (cooks llvm-native first — a full host LLVM build).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The native (host) libclc build was broken at multiple layers; fixed:
1. native_libclc.cmake used literal ${COOKBOOK_SYSROOT} in a single-quoted
heredoc -> CMake saw it empty -> /bin/clang-21. Use $ENV{...} so CMake reads
the env at configure time.
2. Pointed the host compiler at the SYSROOT clang (a Redox-target binary, can't
run on the host). Use $ENV{COOKBOOK_TOOLCHAIN}/bin/clang-21 (host clang,
defaults to x86_64-unknown-linux-gnu).
3. The cross-env restore (LDFLAGS with Redox -L paths + --static) ran BEFORE the
native cmake/ninja, polluting the host link. Moved it to AFTER the build.
4. -DLLVM_DIR overrode the toolchain file with the Redox sysroot LLVM. Point it
at ${COOKBOOK_TOOLCHAIN}.
Compiler detection now passes ('skipped'/OK). REMAINING structural blocker:
find_package(LLVM) loads the toolchain's LLVMExports.cmake but that references
LLVM dev files not shipped in the runtime toolchain -> needs a complete HOST
LLVM dev tree (llvm21 host dev output) for the libclc host build.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Round 11 audit cleanup. Six fixes across six files:
1. local/recipes/system/redbear-passwd/recipe.toml — CRITICAL: was
missing the [source] block entirely. The recipe had only [package]
and [build] with template=cargo, which the cookbook cannot fetch.
Added [source] path = "source" so the cookbook locates the local
Rust crate. Also added a one-line description.
2. local/recipes/dev/libclc/recipe.toml — MEDIUM: the build script
installs via cmake but never verifies that libclc.pc (Mesa's
pkg-config dependency) and the .bc bitcode files actually landed.
Without these, Mesa's 3D driver cook fails opaquely with
'Dependency libclc not found (tried pkg-config)'. Added three
post-install test -f checks that fail the build with a precise
error pointing at the missing path.
3. local/recipes/system/redbear-sessiond/source/src/manager.rs — HIGH:
the D-Bus login1 can_power_off / can_reboot / can_suspend methods
were returning 'yes' unconditionally — the archetype lie-grade-ok
pattern (probe says success, then the real action fails because
/scheme/sys/kstop is missing). Replaced with a kstop_writable()
probe that fs::metadata()s the path. Used metadata() rather than
an actual write because writing 'shutdown'/'reset'/'s3' to
/scheme/sys/kstop would trigger the action. The actual power_off/
reboot/suspend methods still report granular errors when the
write is refused.
4. local/recipes/system/redbear-dnsd/source/src/transport.rs — MEDIUM:
UpstreamConfig::default() hardcoded 8.8.8.8 + 1.1.1.1 as fallback
upstream DNS. Hardcoding third-party DNS bypasses netcfg integration
and leaks user queries without consent on first boot. Replaced with
an empty Vec — main() reads the upstream list from netcfg before
any query is dispatched; upstream queries SERVFAIL until netcfg
populates the list (honest default).
5. local/docs/GREETER-LOGIN-IMPLEMENTATION-PLAN.md — MEDIUM: 16
references to the non-existent binary 'redbear-kde-session' (now
'redbear-session-launch'). Global s/redbear-kde-session/redbear-
session-launch/g. Also updated two 'redbear-kde' profile-name
references to reflect the 2026-07-24 retirement and the current
'redbear-full' ownership of the desktop path.
6. local/docs/DBUS-INTEGRATION-PLAN.md — LOW: 7 references to
'redbear-kde-session' renamed to 'redbear-session-launch' (same
binary rename).
6 files changed, +68/-28.
Note: Mesa 04-sys-ioccom-stub-header.patch migration to relibc proper
(sys/ioccom.h with Linux-style IOC encoding) is deferred — the
patch is a genuine gap-filler (relibc's sys/ioctl.h has the basic
macros but sys/ioccom.h is the BSD include path DRM UAPI expects).
That work belongs in the relibc fork with a prefix rebuild and
should be coordinated with the operator's prefix-staleness policy.
libclc's [source] uses git + path_in_repo="libclc", and the recipe assumed
COOKBOOK_SOURCE would already be the libclc subdir. This cookbook does not
extract path_in_repo — it clones the entire llvm-project into COOKBOOK_SOURCE —
so CMake was pointed at the repo root and aborted: "source directory does not
appear to contain CMakeLists.txt". Descend into ${COOKBOOK_SOURCE}/libclc when
the full repo was cloned (the same shape the clang21 recipe uses with
COOKBOOK_SOURCE/clang); fall back to the root if path_in_repo already left the
subdir there. recipe.toml is committed (not the operator's dirty source WIP).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The libclc CMake config validates target names as
(with double-dash suffix for the unspecified-ABI variant). The
previous 'amdgcn', 'amdgcn-amdhsa', 'r600', 'generic', 'spirv'
names caused:
CMake Error at CMakeLists.txt:156 (message):
Unknown target in LIBCLC_TARGETS_TO_BUILD: 'amdgcn'
Valid targets are:
amdgcn--;amdgcn--amdhsa;clspv--;clspv64--;r600--;nvptx--;
nvptx64--;nvptx--nvidiacl;nvptx64--nvidiacl;amdgcn-mesa-mesa3d
Fix: use the correct names with suffix:
r600-- -> r600 (Southern Islands / Evergreen)
amdgcn-- -> GCN GFX6..GFX12 default-ABI
amdgcn--amdhsa -> GCN with HSA runtime
amdgcn-mesa-mesa3d -> GCN via Mesa3D-specific frontend
The target is excluded because Mesa's clc tool produces
its own spirv .bc files rather than consuming libclc's. Similarly,
nvptx is excluded because there is no NVIDIA path in Mesa.
Verified: 'cmake' with -DLIBCLC_TARGETS_TO_BUILD=... above
configures successfully and 'make' produces all 118 expected .bc
files (r600 devices: cedar/cypress/barts/cayman, amdgcn devices:
tahiti..gfx1201 across all GFX variants). 'make install' places
the .pc file at /share/pkgconfig/libclc.pc (default cmake
pkgconfig location, in pkg-config's standard search path) and the
.bc files at /share/clc/ (which is what libclc.pc's
libexecdir points to).
After this fix, a fresh meson setup of Mesa with the iris/radeonsi
gallium drivers and intel/amd/swrast Vulkan drivers resolves
'dependency(libclc)' successfully — the previous 'Dependency
libclc not found' error goes away, and the gallium-r600 / gallium-
amdgpu / iris paths can compile.
The mesa-recipe's iris/radeonsi/Vulkan configuration is already
in place (per commit b7b8168aae which reverted the libclc-induced
driver drop). With this libclc recipe committed, the recipe build
chain is unblocked.
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.
All tarballs re-downloaded from upstream mirrors, BLAKE3 hashes
verified against downloaded files. Per user request: walk through ALL
recipes, not just graphics. This is the active build pipeline batch.
Cherry-picked from Qt upstream (commit e488f852fa18c2afc2842a88eff8f66ad4105a45).
Original patch source:
https://download.qt.io/official_releases/qt/6.11/CVE-2026-6210-qtsvg-6.11.diff
Fix: Test types of nodes before downcasting them. A bad cast in
QSvgMarker::drawHelper led to endless recursion resulting in a heap
overflow. While fixing that, another similar case was also fixed.
Gnulib generates lib/sched.h which wraps the system sched.h via
#include_next, but the #if @HAVE_SCHED_H@ guard evaluates to 0 during
cross-compilation, preventing sched_param typedef from being visible.
Adding ac_cv_header_sched_h=yes fixes the guard.
fstools.mk: Use canonical local/sources/ paths for installer and redoxfs
cargo install --path. The recipes/ symlink chain caused cargo to resolve
path dependencies (../libredox, ../redoxfs, ../syscall) relative to the
recipe directory instead of the canonical source location, breaking
the host build.
bison: Add cross-compilation cache variables for POSIX spawn support.
Gnulib's configure couldn't detect the system spawn.h during cross-compile,
causing generated lib/spawn.h to omit #include_next, leaving
POSIX_SPAWN_* constants undefined.
The working tree had accumulated git-tracking drift across the
local/sources, local/recipes/*/source, and local/reference trees.
Restored:
- local/sources/libredox: add missing 160000 gitlink at
d01da350 (submodule/libredox). The .gitmodules entry already
declared this fork; the parent tree entry was missing so a
fresh clone of the parent would not pull the libredox source.
- .gitignore: mark the four local/recipes/*/source build-cache
trees (uutils-tar, ninja-build, sddm, sddm/source-pristine)
and the two local/reference/* entries (linux-7.1, seL4) as
ignored. These are build caches and external references, not
durable Red Bear code. The durable code for the four recipes
is recipe.toml + the corresponding patch (redox.patch).
- Note in .gitignore: do not extend local/recipes/**/source to
a blanket rule, because ~150 Red Bear fork recipes do keep
their durable source under local/recipes/<name>/source/.
Removed six broken 160000 gitlinks:
- local/recipes/archives/uutils-tar/source (e4c2affa...): on-disk
working tree was a self-clone of RedBear-OS; gitlink pointed to
a non-existent commit in the parent object database.
- local/recipes/dev/ninja-build/source (d829f42b...): gitlink
was a dangling commit on a diverged branch that has since been
rewritten; the on-disk HEAD is upstream v1.13.1 (79feac0) which
the recipe re-fetches via recipe.toml anyway. The 6.4MB
embedded .git directory was also removed.
- local/recipes/kde/sddm/source (63780fcd...): build cache for
sddm 0.21.0 re-fetched via recipe.toml. The 11MB embedded
.git directory was also removed.
- local/recipes/kde/sddm/source-pristine (63780fcd...): empty
placeholder, build cache. Removed.
- local/reference/linux-7.1 (ab9de95c...): external Linux
reference tree, gitignored by size. The on-disk directory
is preserved per AGENTS.md 'NEVER delete the reference tree'.
- local/reference/seL4 (a0b4f2d2...): empty placeholder,
gitignored.
Removed untracked pollution at repo root:
- kernel (empty 0-byte file)
- qqmljsgrammar.cpp, qqmljsgrammar_p.h, qqmljsparser.cpp,
qqmljsparser_p.h (393KB total: build artifacts that escaped
a qtdeclarative build into the working tree root; they belong
inside the recipe source tree, not at the parent level)
Added:
- local/docs/MULTITHREADING-COMPREHENSIVE-ASSESSMENT-AND-PLAN.md:
comprehensive multi-threading audit and implementation plan
covering kernel scheduler, kernel futex, syscall ABI, relibc
pthreads, and userspace threading correctness. Will drive
the next implementation cycle after the git tracking work
is wrapped.
After this commit:
- 9 submodule entries in HEAD, all of local/sources/* forks.
- All previously-existing 8 fork submodules unchanged.
- libredox is now durable across clones (was previously lost).
- No untracked files at root.
- No dangling or self-referencing gitlinks.
kernel (2 commits):
- drop -Z json-target-spec (redundant with --target)
- add MWAIT idle_loop for deeper C-states on modern CPUs (Phase G)
ninja-build (1 commit):
- add Redox subprocess fork/exec and GetLoadAverage support
- Remove recipe target directories (47GB)
- Clean build directory artifacts
- Remove old temp logs
- Clean Cargo target directories
- Free disk space from 32GB to 91GB available
Core fixes to get redbear-mini building and booting via UEFI:
relibc: Use 'VaListImpl as va_list' in syslog so cbindgen outputs va_list
instead of unknown VaListImpl type (matches stdio pattern). Fixes
openssl3 and all C consumers of syslog.h.
base fork (f97da5b0): ps2d missing info! import, ps2d dead variable,
fbcond drm-0.15 API fix, acpid 31 errors (ivrs/mcfg modules, duplicate
methods, packed fields, dmar copy-paste bug), bootstrap abort_immediate
removal (feature removed from nightly)
redox-driver-sys: Add PciQuirkFlags re-export for crate-root imports
bash: Regenerate P1-mksyntax-host-headers.patch with proper unified diff
m4: Fix getlocalename_l unsafe wrapper
config: Comment out mc (requires glib-2.0 chain, not needed for mini)
UEFI boot verified in QEMU — boots to RedBear login prompt.
Author: vasilito <adminpupkin@gmail.com>
- Create local/docs/PACKAGE-BUILD-QUIRKS.md: central reference for all
known cross-compilation build issues (DYNAMIC_INIT behavior, m4
CFLAGS/LDFLAGS ordering, ninja-build BUILD_TESTING, general patterns)
- Update UPSTREAM-SYNC-PROCEDURE.md: add m4 LDFLAGS ordering quirk
(must be set AFTER DYNAMIC_INIT), ninja-build BUILD_TESTING=OFF,
DYNAMIC_INIT overwrite behavior, source reversion root cause summary
- Update AGENTS.md: reference PACKAGE-BUILD-QUIRKS.md in WHERE TO LOOK
table, add DYNAMIC_INIT and cross-compilation test conventions
- Fix ninja-build recipe: add cmakeflags=['-DBUILD_TESTING=OFF']
(tests require host gtest which conflicts with Redox sysroot stdlib.h)
Base fork workspace pins redox_syscall = '0.7.4' (resolves to 0.7.5).
Without this pin, redox-driver-sys pulls in 0.8.1, causing type mismatches
in downstream crates like driver-graphics that use both 0.7.5 and 0.8.1
types in the same expression.
The previous patch left a broken `__redox__ && HAVE_GETLOCALENAME_L`
branch that referenced the non-existent relibc function `getlocalename_l`,
causing the m4 build to fail with:
error: #error "Please port gnulib getlocalename_l-unsafe.c to your platform!"
Redox's relibc has no `getlocalename_l` symbol. The patch now uses
`__redox__ && !HAVE_GETLOCALENAME_L` and returns "C" (matching
the existing `__ANDROID__` branch behaviour for unknown locales),
so the build no longer hits the gnulib #error.
vasilito