These three carried only `path = "source"` with no origin recorded anywhere, so
nothing could distinguish them from Red Bear's own code and the first-party
integrity gate classified them as ours. URLs and versions taken from evidence
in each source tree, not guessed:
libepoxy github.com/anholt/libepoxy meson version 1.5.10
libxcvt gitlab.freedesktop.org/xorg/lib/libxcvt meson version 0.1.3
libdisplay-info gitlab.freedesktop.org/emersion/... meson version 0.4.0
NOT applied to libpciaccess or libudev, which were named alongside these as
upstream. Their source trees are 2 files / 272 lines and 3 files / 1314 lines
respectively -- these are Red Bear's own minimal implementations of those APIs,
not vendored copies of the upstream projects, which are far larger. Recording a
fake upstream for them would downgrade the gate from fatal to a warning on
first-party code, which is the one error direction that loses work that exists
nowhere else. Flagged for confirmation rather than assumed.
brush records `# Upstream: https://github.com/reubeno/brush`, but the check
matched `upstream:` case-sensitively AND required the URL to end in .tar/.git,
so it missed on both counts and filed a genuine fork as first-party.
Now matches an explicit upstream/snapshot/origin label followed by a URL, any
case. Deliberately NOT any bare URL in a comment: a stray bug-tracker link must
never read as provenance, since that error direction (first-party treated as
vendored) is the one that loses irreplaceable work.
Remaining inaccuracy is missing DATA, not detection. libepoxy, libpciaccess,
libudev, libxcvt and libdisplay-info are upstream projects whose recipes carry
only `path = "source"` with no origin recorded anywhere, so nothing can tell
them apart from our own code. They classify first-party, which is merely
stricter. The real fix is to record their upstream in the recipe.
The name list was wrong in principle. It started as redbear-*, then needed cub,
then tlc -- and protection that depends on someone remembering to edit this file
is not protection. A new internal program starts out unguarded and the omission
stays invisible until the code is already gone. tlc proved it: first-party,
exempt from out-of-tree staging, protected by nothing but this gate, and
matching no pattern.
The real property is structural -- our code has no upstream to restore from. A
recipe is first-party when its recipe.toml records no fetchable origin: no
`tar =`, no `git =`, no upstream URL. That identifies ~96 recipes against the 3
the list covered, so the list was guarding roughly 3% of the exposure.
The heuristic errs toward first-party deliberately. A vendored recipe recording
its origin only in prose gets treated as ours, which just makes drift fatal
instead of a warning. The opposite error loses irreplaceable work, so the
default fails in the safe direction.
Verified: fires on redbear-netctl, cub and tlc (none of which are named
anywhere in the code now); does NOT fire on vendored kirigami; silent on a
clean tree; every probe restores.
Extends the fatal first-party check beyond redbear-* to cub (system) and tlc
(tui). Both are Red Bear's own programs with no upstream anywhere, so the
"restore it from the tarball" recovery that makes vendored drift a warning does
not exist for them.
They sit on opposite sides of the staging boundary, which is why both need the
gate for different reasons:
cub is staged out of tree (no escaping cargo path deps), so staging already
keeps recipe seds off the tracked copy.
tlc is EXEMPT from staging: its manifest has a path dependency escaping the
source tree, so nothing keeps a sed off the real files. For tlc this
gate is the only protection.
The check is now a redbear_is_firstparty() helper rather than an inline glob, so
adding the next internal program is one line.
Verified: silent on a clean tree; fires on a one-line edit to cub and to tlc;
both restore cleanly.
redbear-* recipes are not vendored upstream code -- they are Red Bear's own
programs and exist nowhere else. A vendored tree can be restored from its
tarball or git remote; first-party source cannot. If a recipe sed or an `rm`
damages it and that gets committed, the work is gone.
Not hypothetical. Seven redbear-* recipes rewrite their own source during the
build (greeter, btusb, btctl, ime, dnsd, accessibility, keymapd), and all seven
are exempt from out-of-tree staging because their cargo manifests carry path
dependencies escaping the source tree. They are simultaneously the least
protected and the most irreplaceable code here.
Uncommitted drift in them now fails preflight instead of printing a note that
scrolls past. Vendored trees keep the existing warn-by-default behaviour.
Override: REDBEAR_ALLOW_DIRTY_FIRSTPARTY=1.
Verified: gate is silent on a clean tree, fires on a one-line edit to
redbear-authd, and the tree restores cleanly.
Two systemic fixes for failure classes this session kept re-hitting.
1. COOK_JOBS default 4 -> 1. Recipes are not isolated: redbear_qt_ensure_dep_
sysroots repairs OTHER recipes' sysroots, so one cook can relink the include/
or lib/ directory another is compiling against. The tell was a failure that
MOVED between source files across runs (kirigami died in KirigamiTemplates on
build 59, KirigamiPrivateplugin on 61) with a sibling's rm -f/ln -sf
interleaved in the log. Making the relink atomic closed one window; the
sharing itself remains unsound. Compilation is still parallel -- each recipe
keeps the full -j budget -- only the number of recipes in flight drops to 1.
An intermittent build costs more than a serial one.
2. Auto-reset build dirs whose CMakeCache records a different source path.
CMake stores CMAKE_HOME_DIRECTORY and hard-aborts when the source moves:
CMake Error: The source ".../source-staged/..." does not match the source
... used to generate cache
Out-of-tree staging moved every tracked recipe's source and stranded 66 build
dirs. Two rounds of clearing them by hand were not a fix: the next source-path
change strands them again, and the abort surfaces in a downstream recipe
rather than at the cause. cook now detects the mismatch and resets the dir.
Out-of-tree staging made the checker scan source-staged/, which holds the same
upstream third-party patches as source/ -- already skipped because they are not
ours to fix. qtdeclarative's bundled yoga patch then failed the build at
preflight. Same rationale as the existing /source/ entry.
redbear_qt_ensure_dep_sysroots repairs OTHER recipes' sysroots, so with
COOKBOOK_COOK_JOBS>1 it runs while a parallel cook is compiling against the
very directory it is relinking. It did `rm -f` then `ln -sf`, leaving a window
where the path did not exist. kirigami died in that window:
cstdio:47: fatal error:
.../qtdeclarative/target/.../sysroot/include/stdio.h: No such file
with another cook's `rm -f`/`ln -sf` on qtdeclarative's sysroot interleaved in
the same log.
Now: skip entirely when the link already points at the right target (the
common case, and the cheapest way to stop the churn), otherwise replace via
ln -s to a temp name + `mv -T`, a single rename(2) -- readers see the old link
or the new one, never nothing.
Verified with 300 concurrent relinks against 3000 probes: 0 missing
observations, where the old sequence reproduced the gap.
Points the relibc submodule at 4e9fbf4c. sys/timerfd.h and sys/signalfd.h
declare their prototypes in the cbindgen trailer, which is emitted outside the
extern "C" block cpp_compat generates, so C++ consumers linked against a
mangled name while relibc exports the plain C symbol:
alignedtimer.cpp:(.text+0x29a): undefined reference to
`timerfd_create(int, int)'
(plasma-workspace libclock). C callers were unaffected, which is why it
survived until a C++ consumer appeared.
Also refreshes the tracked-source baseline. This should become largely static
now that cook stages tracked vendored sources out of tree.
libcanberra: plasma-workspace calls find_package(Canberra) TYPE REQUIRED and
includes <canberra.h> from four translation units with no HAVE_CANBERRA guard,
one of them libnotificationmanager (the core notification library). It cannot
be made optional, so it is ported for real. Built shared: it dlopens its
backend through libltdl, the libtool recipe stages libltdl.so only (no .a), so
a static build left every consumer with an undefined lt_dlopenext.
Audio is SILENT. Upstream 0.30 offers alsa/oss/pulse/gstreamer/null and none
speak Redox; the pulse driver needs PulseAudio's client library, which PipeWire
does not provide. The null driver is real upstream code, so the API/ABI is
genuine and all consumers work -- but nothing reaches the speakers until a
native /scheme/audio driver exists.
KX11Extras et al: gate the five X11-only KWindowSystem headers behind the
HAVE_X11 that plasma-workspace already defines. X11 is compiled OUT, not added.
gate-kx11extras.py brace-matches each block and keeps any trailing else outside
the guard, since wrapping a whole if/else-if chain yields invalid C++.
check-recipe-escapes.py: a single backslash in a TOML multi-line string is a
TOML escape, so a sed written as \bFoo\b parses to <BS>Foo<BS> and silently
matches nothing -- no TOML error, no sed error. This class bit the tree three
times. Now gated in preflight; it also found openssh, which used an invalid \$
and could not be parsed by any compliant parser.
cook_build.rs: build git-tracked vendored sources OUT OF TREE. Recipe scripts
rewrite their source, so builds were mutating version-controlled files: a
no-op sed became indistinguishable from a working one, and the integrity gate
fired so often that clearing it stopped being protective. Uses
cp -a --reflink=auto, not cp -al: sed -i is link-safe but `cp -f` and `>`
truncate in place and would write through a hard link into the tracked
original. Content hashing still runs against the pristine tree, so hashes now
describe committed state. Escape hatch: REDBEAR_IN_TREE_BUILD=1.
Unblocks plasma-workspace/plasma-desktop, which required 14 packages that had
no in-tree recipe. Sources are reproducible from each recipe's tar= + blake3;
the vendored source/ trees are deliberately not committed here (212M).
New recipes:
KF6 6.28.0 kf6-kholidays, kf6-krunner, kf6-kstatusnotifieritem,
kf6-kunitconversion
Plasma 6.7.2 knighttime, layer-shell-qt, libkscreen, libksysguard,
plasma-activities-stats, plasma5support, kscreenlocker
Qt 6.11.1 qtpositioning, qtspeech, qttools
libksysguard carries P0-redox-process-backend.patch: processes_local_p.cpp
dispatches on platform macros and had no __redox__ arm, so ProcessesLocal was
entirely undefined. Adds a real backend reading /scheme/proc/ps (pid, ppid,
real+effective ids, thread count, state) and /scheme/sys/mem, with kill() for
signals. Upstream's generic fallback is a pure stub and was not used. Absent
facilities (no setpriority/sched_setscheduler/ioprio on a microkernel) report
NotSupported rather than pretending.
Restored, no longer disabled:
- night colour: kcms/nighttime + kwin's nightlight plugin, now that
KNightTime/Qt6Positioning/KF6Holidays exist
- KIO FileWidgets (file dialog, places model), wrongly swept in with the
unportable kiod/kssld/kioworkers subdirs
- kf6-ktexteditor text-to-speech: removes a disguised stub that rewrote
speechEngine() to return nullptr and mangled call sites into invalid C++
- kwin KWIN_BUILD_SCREENLOCKER=ON (needs kscreenlocker; see below)
Toolchain and recipe fixes:
- redox-toolchain.cmake: append -lgcc. __extendhfsf2/__extendbfsf2 are
global in libgcc.a but hidden in libgcc_s.so (the Redox libgcc version map
stops at GCC_7.0.0 and never emits the GCC_12/13 nodes upstream exports),
and GCC omits -lgcc for -shared, so no C++23 shared library using
std::format<_Float16|bfloat16_t> could link.
- qtmultimedia: rewrite /usr/src/.../meta_types paths and stage metatypes,
so consumers using qt_internal_add_qml_module can configure.
- qtspeech: qtmultimedia is mandatory, not optional -- upstream return()s
with only a NOTICE without it, yielding a green build over an empty
package. Asserts its own output so that cannot recur.
- narrow Linux-only guards with AND NOT REDOX where the toolchain sets
CMAKE_SYSTEM_NAME=Linux purely to get UNIX=TRUE (kio LibMount,
libksysguard NL/Sensors, plasma-workspace NetworkManagerQt).
- drop REQUIRED components that are declared but referenced nowhere
(Location, QCoro6, Qt6 Test) -- verified by exhaustive grep.
- DESTDIR installs where KDE emits absolute KDE_INSTALL_FULL_* paths that
--prefix cannot re-root, which otherwise write into the build host.
Auth stack:
- pam-redbear: add PAM_MODULE_UNKNOWN (28), missing from both the header and
lib.rs; realign 30/31 to Linux-PAM's PAM_CONV_AGAIN/PAM_INCOMPLETE, which
previously held Red Bear-only names on standard values, so anything built
against stock PAM headers mis-decoded them.
- redbear-authd: support yescrypt ($y$ -- the default shadow format on
current Debian/Ubuntu/Fedora, previously an unexplained login failure),
bcrypt and md5-crypt. Plaintext shadow entries now require the
/etc/redbear/allow-plaintext-passwords sentinel and warn on every use,
instead of being compared silently. 19/19 host tests pass.
Build-system hardening:
- verify-tracked-sources.sh, wired into preflight: fails on deletion of any
tracked vendored source, and on modifications with no baseline entry.
local/sources/ had a dirty gate and version checks; local/recipes/*/source/
had none, which allowed an rm -rf to delete 7958 tracked files and a
pristine re-extract to silently overwrite committed fixes (kwin's
std::expected/vulkan-hpp and X11 gating, kio's Q_OS_REDOX resolver guards).
- validate-source-trees.py: resolve recipe.toml through the overlay symlink;
it reported false MISSING for symlinked recipes.
- test-sddm-virgl-qemu.sh: the null-proxy check used report(), which PASSES
on regex match -- so the known Qt6 Wayland null+8 fault would report PASS
when present. Added report_absent().
kscreenlocker builds only its cmake-level Wayland-only changes so far; the
C++ X11 removal (61 call sites) is not yet applied, so kwin's screenlocker
flag is blocked on it.
The recipe was not building libdisplay-info. It synthesized its own
meson.build declaring `version: '0.2.3'` and compiled a hand-written
stub: one di.c and four headers, 518 lines, 20 exported functions.
0.2.3 does not exist upstream -- the tags are 0.1.0, 0.1.1, 0.2.0, 0.3.0
and 0.4.0. That fabricated version satisfied kwin's
pkg_check_modules(libdisplayinfo REQUIRED IMPORTED_TARGET libdisplay-info>=0.2.0)
so kwin configured cleanly and then failed to compile utils/edid.cpp on
di_info_get_default_color_primaries, di_info_get_hdr_static_metadata,
di_info_get_supported_signal_colorimetry and di_edid_display_descriptor.
A version gate satisfied by a declaration rather than an implementation.
Now vendors upstream 0.4.0 (gitlab.freedesktop.org/emersion/libdisplay-info):
14 C files, 10898 lines, 10 headers, 94 exported symbols. 0.4.0 rather than
0.2.0 because the colorimetry and HDR static metadata accessors kwin needs
post-date the 0.2.x series -- and they feed the real colour-primaries and
HDR path of the display stack, so a stub returning NULL would have been
wrong at runtime even if it had compiled.
Red Bear delta is one hunk in source/meson.build: the unconditional
subdir('di-edid-decode') and subdir('test') are commented out. Both build
auxiliary executables and a shell test harness that are not part of the
runtime and do not cross-compile for Redox. Library, headers and
pkg-config are untouched.
Verified: builds clean, stages libdisplay-info.so.0.4.0 with all four
symbols kwin needs, pkg-config reports 0.4.0, and kwin's utils/edid.cpp
now compiles.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Continues the previous kwin commit; all found by compiling further.
vulkan-hpp (VULKAN_HPP_RAII_NO_EXCEPTIONS, now active because GCC 16's
libstdc++ provides __cpp_lib_expected at C++23):
- vulkan_device.cpp getQueue() returns CreateReturnType<Queue>, an
expected, not a Queue -- unwrapped via splitResult().
- CommandBuffer::begin/end, bindImageMemory2, importSemaphoreFdKHR and
Queue::submit return void, not vk::Result. They route their Result
through detail::resultCheck -> VULKAN_HPP_ASSERT_ON_RESULT, which this
build defines to `void`, so the status is discarded by configuration.
Assigning them to vk::Result no longer compiles. Noted at each site;
the eErrorDeviceLost branch after Queue::submit is now unreachable.
- mapMemory() returns void* and needed wrapping.
- QueryPool::getResults already returns a decomposable std::pair, so
splitResult() had double-wrapped it; unwrapped.
X11 gating -- KWIN_BUILD_X11=OFF is set correctly by the recipe, but
several includes sit outside the guard their own uses are inside:
- workspace.cpp included syncalarmx11filter.h unguarded (both uses and
the workspace.h member are guarded).
- shadow.h declared readX11ShadowProperty(xcb_window_t) unguarded while
shadow.cpp guards the definition.
- effecthandler.h declared unique_ptr<WindowPropertyNotifyX11Filter>
unguarded; with X11 off the type is only forward-declared and
~unique_ptr needs it complete.
Missing includes, same shape as earlier findings -- the declaration exists,
it just never reaches the compiler:
- tabletmodemanager.cpp and backends/libinput/device.cpp call udev_device_*
without including <libudev.h>, which upstream gets transitively through
libinput.h. Ours does not pull it in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
qtbase configured with QT_FEATURE_xkbcommon=OFF because libxkbcommon was
never staged into its sysroot -- the recipe existed but nothing depended
on it. With the feature off, qtbase does not install
QtGui/private/qxkbcommon_p.h (src/gui/CMakeLists.txt:1095 is conditional
on it), so kwin's inputmethod.cpp failed with
inputmethod.cpp:51: fatal error: private/qxkbcommon_p.h: No such file
kwin also includes <xkbcommon/xkbcommon-keysyms.h> directly while
declaring no such dependency, relying on it arriving transitively; that
is now explicit.
Another latent gap rather than GCC 16 fallout -- it only surfaced once
kwin compiled far enough to reach this include.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vulkan-hpp switches every vk::raii create/enumerate/get return from the
decomposable vk::ResultValue to VULKAN_HPP_EXPECTED once
VULKAN_HPP_NO_EXCEPTIONS is set (kwin does, src/CMakeLists.txt) and the
standard library provides __cpp_lib_expected at C++23. GCC 16's libstdc++
has it and GCC 13's did not, so the toolchain upgrade silently changed the
API shape under kwin 6.7.2 and 20 call sites stopped compiling with
"cannot decompose class type 'std::expected<...>'".
There is no ResultValue path left to fall back to: vulkan_raii.hpp with
NO_EXCEPTIONS but no expected emits calls to throwResultException, which
NO_EXCEPTIONS compiles out. Declining the switch is not available.
So splitResult() (src/vulkan/vulkan_result_compat.h) restores the
(result, value) pair those sites are written against, and each site is
wrapped mechanically. The surrounding control flow stays exactly as
upstream wrote it rather than being rewritten around a different idiom.
Not every such call is still fallible in this header revision, so the
helper also passes plain payloads through paired with eSuccess.
Separately, two X11-only includes were never guarded, and only showed up
now because no xcb headers are staged for Redox:
- effect/effecthandler.cpp included window_property_notify_x11_filter.h
unguarded while every *use* of that type sits inside #if KWIN_BUILD_X11,
and x11window.h two lines below is guarded. A plain upstream oversight.
- screenedge.h included <xcb/xcb.h> while referencing no xcb_* type at all.
Both now use KWIN_BUILD_X11, matching the file's own idiom.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The recipe lists 02-qnetwork-real-implementation.patch, but the symlink
into the recipe directory was absent, so fetch failed outright:
repo: failed to fetch: Failed to find patch file
"recipes/kde/kirigami/02-qnetwork-real-implementation.patch"
The patch itself was never lost -- it is in local/patches/kirigami/ and
its content is already applied in the vendored source (icon.cpp carries
the QNetworkAccessManager work). Only the link was missing, because
recipes/**/*.patch is gitignored and this one was never force-added, so a
clean checkout could not resolve it.
Force-added, as done for the other patch symlinks this session. Swept the
rest of local/recipes for the same defect: no others.
kirigami cooks clean. The vendored source tree (493 tracked files) was
left untouched, per local/AGENTS.md LOCAL RECIPE SOURCE IMMUTABILITY.
gcc13 was still being built despite gcc-native/rust-native being
deferred, and it failed the whole build: binutils-native pulled it
transitively. It is the same dependency pattern already removed from
gcc-native -- what the recipe actually needs is a cross compiler, and
that comes from the prefix toolchain on PATH
(x86_64-unknown-redox-gcc, now 16.1.0), not from a cooked gcc13 package.
Keeping it meant building GCC 13 with GCC 16, which does not work: the
host link fails with the libstdc++ 128-bit float helpers unresolved
(__eqtf2/__getf2/__gttf2/__letf2/__unordtf2 against
/usr/lib/gcc/x86_64-pc-linux-gnu/16/libstdc++.so), a host/target libgcc
leak, and beyond that GCC 16 ICEs on GCC 13's libsupc++. See
local/docs/NATIVE-TOOLCHAIN-WORKSTREAM.md.
binutils-native cooks clean without it.
The config comment referencing this file was dangling. Captures the
twelve gcc-native and four rust-native findings so the work is not lost:
the GCC 13 -> 16 move and why (char8_t, libcody's C++11-only probe, the
cpuid macros GCC 15/16 removed, then an ICE), the stale same_as symlink,
the gnu17 exemption, the missing relibc dependency, the getopt.h
shadowing, and the fnmatch extensions implemented in the fork.
Records two things explicitly because they are easy to get wrong again:
- The old 'Redox C++/pthread header gaps' justification was false.
llvm-native cooks clean in isolation; it only failed in parallel builds
because of a cookbook race on shared staging paths. A build-system bug
had been misdiagnosed as a porting gap and used to exclude a required
package.
- My own 'relibc fenv.h is a stub' diagnosis was also false. relibc
delegates to openlibm_fenv.h which defines both types; the header just
was not reaching the sysroot. Generalised into a rule: an undeclared
identifier against relibc is more often a header-path problem than a
missing implementation.
Also notes the exact stopping point (host libstdc++ headers leaking into
a target compile), the re-enable procedure, and the advice to diagnose
with COOKBOOK_COOK_JOBS=1 since several wrong turns came from attributing
one recipe's error to another in the interleaved parallel log.
syscall
submodule/syscall had diverged from origin -- 18 local commits against
19 on the remote, with matching subjects and different SHAs, i.e. the
local branch had been rewritten at some point. Rather than force-push
and discard 19 published commits, rebased local onto
origin/submodule/syscall. git absorbed 16 duplicates by patch-id,
leaving two genuinely local commits (NUMA support, which origin does
not have at all, and the 0.3.2 version bump).
Verified no work was lost: the rebased tree is byte-for-byte identical
to the pre-rebase state apart from the Cargo.toml version line, and a
backup/pre-rebase-* branch is kept. Two Cargo.toml conflicts were
version-label collisions only, resolved to 0.9.1+rb0.3.1 mid-series and
0.9.1+rb0.3.2 at the tip, per the Cat 2 convention. The push is now a
fast-forward and the gitlink is updated to the rebased SHA.
native toolchain
gcc-native and rust-native set to "ignore" -- explicit operator
decision, 2026-08-03: 'Treat gcc-native/rust-native as a separate
workstream, explicitly deferred by me, for now.' That is the one
condition AGENTS.md ABSOLUTE RULE permits an exclusion under. It is not
an agent-initiated removal, and not a repeat of the 'not needed for
greeter proof' hand-wave that previously hid real breakage -- that
suppression was reverted first, which is how the defects were found.
binutils-native and llvm-native stay in the target; llvm-native is
required for libclc and Mesa's iris/radeonsi CLC path. The recipes for
the deferred pair are fixed and committed, not reverted.
Follows the recipe's [source] move from same_as gcc13 to
path = "../gcc16/source". The old symlink pointed at
recipes/dev/gcc13/source and survived the recipe edit, which is why the
first GCC 16 build attempt was still compiling GCC 13 sources.
libiberty compiles getopt1.c against GCC's include/getopt.h, which
declares the GNU-internal _getopt_internal. relibc ships a getopt.h that
does not declare it and was shadowing GCC's:
getopt1.c:71: error: implicit declaration of function
'_getopt_internal'
Same shape as the cpuid.h shadowing already handled in recipes/dev/gcc13.
Verified: _getopt_internal errors 5 -> 0.
STILL FAILING, on a new and different phase: the HOST libstdc++ headers
are being pulled into the build --
/usr/include/c++/16/x86_64-pc-linux-gnu/bits/os_defines.h:44:
error: missing binary operator before token '('
which is __GLIBC_PREREQ evaluated where there is no glibc. That is a
host/target header leak, not a continuation of the getopt problem, and it
is unrelated to this commit's change.
Two corrections.
relibc dependency restored. Dropping gcc13 from gcc-native's deps also
removed what transitively staged relibc's headers, leaving the sysroot
with no libc headers at all -- no fenv.h, so libstdc++'s <cfenv> failed
with 'fenv_t has not been declared in ::'.
That corrects my earlier diagnosis: relibc's fenv.h is NOT a stub. It
delegates to openlibm_fenv.h, which dispatches on __x86_64__ to
openlibm_fenv_amd64.h where fenv_t and fexcept_t are both defined, and
relibc stages all of those headers. The header was simply never reaching
this recipe's sysroot. The previous commit message asserting a relibc
fenv gap was wrong.
relibc gitlink bumped for the fnmatch commit, which adds the GNU
FNM_FILE_NAME and FNM_LEADING_DIR that GCC 16's libiberty needs.
Repointed [source] from the gcc13 recipe to the Redox-ported GCC 16 tree
(local/recipes/dev/gcc16/source, upstream 16.1.0 + gcc-redox-port), which
is what produced the working cross toolchain in prefix/.
Building GCC 13 with the GCC 16 cross compiler was not a supported
configuration and each fix only revealed the next incompatibility -- a
C++11 pin for libcody, GCC 13's cpuid.h shadowing the toolchain's after
GCC 15/16 removed the withdrawn AVX512PF/ER/4VNNIW/4FMAPS and PREFETCHWT1
macros, and finally an ICE in gimple_build_eh_must_not_throw compiling
libsupc++. All three are gone on GCC 16: ICE 0, char8_t 0, cpuid 0.
Also fixed here:
- The stale same_as symlink (source -> recipes/dev/gcc13/source) survived
the recipe edit and kept feeding GCC 13 sources to the build. Removed.
- gcc13/gcc13.cxx dropped from dependencies: they build the compiler this
recipe no longer uses. The cross compiler comes from the prefix on PATH.
- Exempted from the tree-wide -std=gnu17 pin. That pin exists for the
C17-era recipes, but GCC 16's own sources are C23 and use `bool` as a
keyword: gcc/config/i386/i386.h:1722: unknown type name 'bool'.
- [package].version set explicitly -- same_as used to supply it, and a
path source leaves the cookbook nothing to infer from.
- Version-globbed the hardcoded 13.2.0 libgcc copy paths.
BLOCKED on a genuine relibc gap. libstdc++'s <cfenv> does
using ::fenv_t; using ::fexcept_t;
but relibc's fenv.h is a 3-line stub defining neither, so
libstdc++-v3/include/fenv.h fails. fenv.h is a C99/POSIX header owed
fenv_t, fexcept_t, the FE_* macros and the fe* functions. Implementing it
in the relibc fork is the fix -- per LOCAL-FORK-SUPREMACY-POLICY.md Rule 2
the fork must be complete -- and is real work, not a flag.
version = "0.2.189" -> "0.2.189+rb0.3.2", per local/AGENTS.md
"Version conventions": every Cat 2 fork is <upstream>+rb<branch>. The
label is what makes the fork traceable to both its upstream base and the
Red Bear branch it was built for.
+rb is build metadata, which semver ignores when matching, so ^0.2
requirements still resolve to the fork -- confirmed, the rust lockfile now
reads libc v0.2.189+rb0.3.2 from the path source. A -rb suffix would be
read as a pre-release and would NOT satisfy them, which is exactly why the
project mandates +rb.
Two things this surfaced:
- fork-upstream-map: libc moved from snapshot to diverged. The fork is
vendored from the crates.io PACKAGE, whose file set differs from the
upstream git tag by construction (no .github/, adds
.cargo_vcs_info.json), so a tag content-diff reported differences that
mean nothing -- 'missing files that exist in upstream' for files the
package never ships. diverged states the real relationship.
- local/recipes/dev/gcc16/.vendored-upstream added. Extracting GCC 16.1.0
put upstream's vendored Rust crates under local/recipes/*/source/, so
sync-versions.sh treated datafrog/log/polonius-engine as Cat 1 in-house
crates and wanted to stamp them 0.3.2. The marker is the documented
escape hatch (BUILD-SYSTEM.md section 7).
Both gates clean: verify-fork-versions reports no violations,
sync-versions --check reports no gcc16 drift.
The fork was an unmapped tree -- verify-fork-versions.sh reported
'libc NOT-MAPPED'. Register it properly so it is governed like every other
Cat 2 fork rather than sitting outside the checks:
- local/fork-upstream-map.toml: libc -> rust-lang/libc 0.2.189, snapshot
mode (vendored from the registry, so its history is unrelated to
upstream's), with the temporary status noted inline.
- verify-fork-versions.sh: src/unix/redox/mod.rs added to the declarative
expected-differ list, so the content check keeps verifying the rest of
the tree instead of being blanket-skipped.
- local/docs/VENDORED-LIBC-FORK.md: what the fork adds, the relibc source
and evidence for every symbol, why the values come from relibc rather
than Linux (Redox's idtype_t is c_int where glibc uses an enum), and a
five-step retirement procedure.
- local/AGENTS.md: listed in the fork table, marked temporary.
Kept vendored for as long as it is required. The gap is upstream-
reportable and belongs in the libc crate.
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.
rustc_llvm compiles llvm-wrapper/*.cpp, which include
"llvm/Config/llvm-config.h". Those headers ship in the .dev package, and
rust-native listed only llvm-native and llvm-native.runtime, so the build
failed with
LLVMWrapper.h:6:10: fatal error: llvm/Config/llvm-config.h:
No such file or directory
even though the header was staged at
llvm-native/target/<triple>/stage.dev/usr/include/. recipes/dev/rust
declares the equivalent llvm21.dev for the same reason.
Latent because rust-native was commented out of the config and had never
been built.
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.
Three defects that were latent until GCC 14+ made implicit declarations
and pointer-type mismatches errors. None was a missing implementation --
in every case the code existed and only the declaration was wrong.
libinput
Carried its own bundled libudev.h that shadowed the real one from the
libudev recipe, which it already declares as a dependency. The bundled
copy lacked udev_device_get_sysattr_value(), so udev/libinput-device-
group.c got an implicit declaration and then an int-to-pointer
assignment. The real header is a strict superset -- nothing is declared
in the bundled copy that the real one lacks -- so the bundled file is
dead code that shadows a real implementation, which
LOCAL-FORK-SUPREMACY-POLICY.md Rule 4 requires removing.
linux-kpi
ieee80211_register_rx_handler() is fully implemented in
src/rust_impl/mac80211.rs as #[no_mangle] extern "C", and
ieee80211_rx_drain()'s own doc comment refers to it, but it was never
declared in c_headers/net/mac80211.h. Declared it.
redbear-iwlwifi
- rb_iwlwifi_bridge_register_rx() is used ~1800 lines before its
definition with no forward declaration. Added one at file scope.
- bridge_rx_callback was declared here as taking void *hw, while its
Rust definition in src/bridge/callback.rs takes *mut Ieee80211Hw and
linux-kpi's RxCallback type expects struct ieee80211_hw *. The C
declaration was simply wrong; corrected to match the implementation.
All three cook clean.
uutils / onig_sys
oniguruma guards its alloca.h include on the autoconf macro:
#if defined(HAVE_ALLOCA_H)
# include <alloca.h>
#endif
onig_sys is compiled by the `cc` crate, so no configure ever runs and
nothing defines it. Under GCC 14+ the resulting implicit declaration is
an error, so uutils failed at
regint.h:271: error: implicit declaration of function 'alloca'
relibc does ship <alloca.h>, so declare it in the cookbook's C flags.
This asserts a fact about the sysroot rather than silencing a warning,
and is what a cross-build environment is expected to supply for sources
that have no configure step. Packages whose own configure defines it to
1 are unaffected -- identical redefinitions are not diagnosed.
netutils
Declares `libredox = "0.1"`, a version string, so cargo resolved
libredox and its transitive redox_syscall from crates.io instead of the
forks. With the forks now at 0.1.19 / 0.9.1 the crates.io side is not in
the offline cache and the build died with
failed to download `redox_syscall v0.9.0`
Caused by: attempting to make an HTTP request, but --offline was
specified
local/AGENTS.md 'Local fork dependency rule (ABSOLUTE)' prohibits
version strings for crates that have a local fork, for exactly this
reason -- a second copy of the crate in the graph gives mismatched
types, and offline builds cannot resolve it at all. [patch.crates-io]
now redirects the direct and transitive resolutions onto the forks.
Both cook clean.
Three GCC 16 gaps found by the redbear-full build.
-fhardened (seatd and other meson recipes, 24 errors)
-fhardened is a host-glibc hardening bundle x86_64-unknown-redox cannot
implement, but GCC accepts it on the command line, so meson's
cc.has_argument('-fhardened') probe answers YES and meson adds it to
every compile. GCC then refuses it for real:
cc1: error: '-fhardened' not supported for this target [-Werror]
Note the tag is [-Werror], not [-Werror=hardened] -- it is an
unconditional warning, so -Wno-hardened does not silence it (tried, and
it did not). The flag has to be cancelled instead; -fno-hardened does
that cleanly and the cookbook's flags are appended after the project's
own, so it wins. Nothing is weakened: the compiler is telling us the
option is inert on this target.
termcap (two independent defects, both latent until now)
1. Makefile.in hardcoded 'CFLAGS = -g' and has no @CFLAGS@ substitution
at all, so nothing configure resolved ever reached the compiler --
including the toolchain's default C dialect. termcap is pre-ANSI
code, so being compiled as GCC 16's default C23 failed at once with
'too many arguments to function malloc; expected 0, have 1'.
Substituting @CFLAGS@ is what a normal autotools Makefile.in does.
2. With CFLAGS flowing, the remaining errors were implicit declarations
of strlen/memcpy/exit/write, which GCC 14+ makes errors regardless of
-std. Cause: autoconf 2.70+ removed AC_HEADER_STDC, so STDC_HEADERS
is never defined and termcap.c/tparam.c took their pre-ANSI branch,
declaring 'char *malloc ();' instead of including <stdlib.h>.
Autoconf's guidance on dropping AC_HEADER_STDC is to assume those
headers exist, which holds for every target Red Bear builds.
pam-redbear
Cargo.lock missed by the earlier sweep; regenerated for the 0.3.2 fork
versions.
termcap and seatd now cook clean.
gettext failed to link against the GCC 16 toolchain with
ld: libc.a(...rcgu.o):(.bss.error_message_count+0x0): multiple
definition of `error_message_count'; libgrt.a(libgrt_a-error.o):
first defined here
Root cause is a cross-compile artefact, not a compiler change. gnulib's
check for a working error() is a RUN test, so cross-compiling reports
'checking for working error function... guessing no' and turns on
GNULIB_REPLACE_ERROR. Two things then go wrong at once: consumers are
redirected to rpl_error, and gnulib's own error.c -- listed in
am__objects_5 with no GL_COND_OBJ_ERROR guard -- still defines the
unrenamed error_* globals, which collide with relibc's.
relibc genuinely implements error(), error_at_line() and all three
globals (verified with nm). Two coordinated fixes:
- gl_cv_func_working_error=yes in the recipe. Stating the answer a run
test cannot reach while cross-compiling is the standard autoconf
mechanism, and is exactly what the neighbouring ac_cv_/gt_cv_ entries
already do for the same reason. Consumers now call relibc's error()
and no rpl_error reference remains.
- Guard gnulib's error.c on HAVE_ERROR, which configure already defines
as 1 -- upstream gnulib later made this module conditional on the
system lacking error(); this snapshot computes the right answer and
does not act on it. Without this the definitions still collide, since
relibc is Rust and one codegen unit carries several symbols, so
referencing any of them drags the whole object in. glibc escapes this
only by giving each its own object file.
gettext cooks clean. Patch generated by diff, applies at --fuzz=0.
Remaining hunks from the doc pass: local/AGENTS.md and the
legacy-superseded SUPERSEDED.md still cited the driver-manager
ASSESSMENT-2026-07-22 / D5-AUDIT evidence files and the archived
migration plan as if they were openable. Cargo.lock picks up the
0.3.1 -> 0.3.2 Cat 0 and installer versions.
argp-parse.c and argp-help.c wrap the whole alloca-declaration block in
'#ifndef __GNUC__', so the header is never included when building with
GCC -- the code relied on GCC historically providing an implicit
declaration. GCC 14 promoted -Wimplicit-function-declaration to an error
and C23 removed implicit declarations, so the GCC 16 cross toolchain
fails:
argp-parse.c:1227:36: error: implicit declaration of function 'alloca'
argp-help.c:1329:35: error: implicit declaration of function 'alloca'
configure already sets HAVE_ALLOCA_H 1 and relibc's <alloca.h> defines
alloca(size) as __builtin_alloca(size), which is what GCC wants. Honour
HAVE_ALLOCA_H before consulting __GNUC__; non-GCC paths are untouched.
Patch generated by diff against pristine source, applies at --fuzz=0,
and the recipe cooks clean. Second opportunistic C23-era fix under the
gnu17 migration, after libiconv.
The libredox 0.1.19 / redox_syscall 0.9.1 bump left 45 recipe lockfiles
pinning libredox 0.1.18+rb0.3.1 and redox_syscall 0.9.0+rb0.3.1. The
cookbook builds with --locked, so every affected recipe died with
error: cannot update the lock file .../Cargo.lock because --locked was
passed to prevent this
which is what took out redox-driver-sys -- and with it every Red Bear
driver -- during the redbear-full build. Regenerating the fork lockfiles
was not enough; the recipes that consume the forks as path deps carry
their own. This is step 6 of local/docs/FORK-BUMP-PATCHING-POLICY.md
applied to the recipe layer.
Also drop the hardcoded GCC version in recipes/libs/libstdcxx-v3: the
literal include/c++/13.2.0 stopped resolving the moment the cross
toolchain moved to 16.1.0, leaving -I pointing at a directory that does
not exist. Now resolves the newest installed C++ header directory and
fails loudly if there is none. Same failure class as the hardcoded
13.2.0 in mk/prefix.mk.
Note: a few recipe-level Cargo.lock files (redox-driver-pci, cpufreqd,
redbear-acmd/-ecmd/-ftdi) sit beside a recipe.toml whose [source] is
path = "source", so they are not build inputs; redox-driver-pci's even
references a redox-driver-core/Cargo.toml that does not exist. They are
left alone rather than given meaning they do not have.
redox-driver-sys now cooks clean.
Round 18's N22 'stale-doc removal' deleted three docs on the stated
premise that they had 'no references anywhere in the repo'. That premise
was wrong for two of them, and SUPERSEDED-DOC-LOG.md's recorded
absorption destinations for those two do not exist:
- CUB-PACKAGE-MANAGER.md was said to be absorbed into a 'redbear-cub
recipe README.md' and NETWORKING-IMPROVEMENT-PLAN.md section 8.2.
Neither exists -- there is no cub README under local/recipes/system/cub,
and that plan has no package-manager section (its 'cubic' matches are
TCP congestion control). README.md meanwhile links the doc from its
Documentation list and names cub in six places, so this left a headline
component with no documentation at all.
- BLUETOOTH-IMPLEMENTATION-PLAN.md was said to be merged into
NETWORKING-IMPROVEMENT-PLAN.md section 3.x. That file contains three
passing mentions of Bluetooth, not a 703-line plan. local/AGENTS.md,
docs/README.md and docs/07 all still list it as a first-class subsystem
plan, and AGENTS.md forbids treating Bluetooth as secondary.
Both restored from aa480f7ca3^ and their SUPERSEDED-DOC-LOG entries
retracted with the reason. USB-VALIDATION-RUNBOOK.md's supersession is
genuine -- USB-IMPLEMENTATION-PLAN.md carries the runbook as section 6.x
test procedures -- so it stays removed and its one reference now points
there.
Also de-dangled references to docs the authorised 2026-07-27
consolidation (092d1b39c3) removed but which canonical docs still cited
as openable: the driver-manager ASSESSMENT-2026-07-22 and D5-AUDIT
evidence files and the archived migration plan, across eight documents.
They now name what they were and where the supersession is recorded.
Remaining unresolved references are upstream KWin's vendored README
pointing at upstream's own CONTRIBUTING.md, which is deliberately not
touched.
verify-fork-versions.sh reads the 4th column of fork-upstream-map.toml
and skips the content check for forks marked 'diverged', with a WARN.
verify-fork-functions.sh had no notion of mode and hard-failed every
fork, so kernel (30), bootloader (5) and installer (2) blocked every
canonical build for drift the map itself records as accepted, with
comments saying a full rebase is later work.
Both verifiers now read the same source of truth. Diverged forks are
reported and counted as warnings; every other fork still gates. This
turned a 5-fork / 43-function hard failure into 2 real findings, which
are fixed in the accompanying relibc and base commits.
Cargo.lock in seven forks still named libredox 0.1.18+rb0.3.1 and
redox_syscall 0.9.0+rb0.3.1. Cargo rewrites them on first build, which
then trips the dirty-source gate mid-run. Regenerated offline and
committed so fingerprints reflect committed state.
New local/docs/FORK-BUMP-PATCHING-POLICY.md, wired into AGENTS.md,
local/AGENTS.md and docs/README.md. Core rule: a version bump is a
REBASE, never a REPLACEMENT.
Written from the libredox 0.1.19 incident, which hit three failures at
once -- wholesale replacement that dropped the acpi re-export,
F_DUPFD_CLOEXEC, the mandated authors entry and the Single-Repo
repository URL; a version-named branch that also tripped the build's
fork-branch gate; and a stale fork-upstream-map.toml that failed
verify-fork-versions.sh with a fake-label violation. Covers the vendored
recipe-fork mirror image (metadata moves, build input does not -- how Qt
shipped 6.11.0 against a 6.11.1 recipe), patch handling during a bump,
and toolchain bumps as version bumps.
Also fixes the two bookkeeping gaps that failed this build:
- local/fork-upstream-map.toml: libredox 0.1.18 -> 0.1.19, never updated
when the fork was bumped.
- verify-fork-versions.sh: record redoxfs's legitimate divergence in the
declarative allowlist the script already provides for libredox, with
the originating commit for each file -- a936d00 (Red Bear, Vec from
alloc for no_std bootloader builds) for filesystem.rs and record.rs,
852a971 (Red Bear, RecvFd EOPNOTSUPP) for mount/redox/mod.rs, and
d807dd3 (upstream symlink fix imported ahead of the 0.9.1 tag) for
mount/redox/scheme.rs. Documented rather than bypassed with
REDBEAR_SKIP_FORK_VERIFY.
Docs:
- Baseline was stated as 0.3.1 across the canonical set while the branch,
Cat 0/1 crates and every Cat 2 fork are 0.3.2. AGENTS.md also cited a
sources/redbear-0.3.1/ archive that does not exist; the only archive
present is sources/redbear-0.1.0/. Versioning examples now match the
forks as they actually stand (redoxfs/syscall 0.9.1, libredox 0.1.19).
- Repaired 18 instances of 'immutable archived' across 8 documents, where
a global find/replace had turned sync/synced/archived into that phrase
and produced ungrammatical text ('never auto-immutable archived',
'### Source immutable archived').
- Settled the apply-patches.sh contradiction empirically. Both sides were
wrong: the GROSS WARNING blocks (x5) described it as routine
patch-linking, and SCRIPT-BEHAVIOR-MATRIX.md said build-redbear.sh
'never invokes' it. It is invoked at build-redbear.sh:487, but only to
auto-repair a failed verify-overlay-integrity.sh check.
- Dropped the dangling reference to a local/AGENTS.md section
'NO OVERLAY-STYLE PATCHES — SCOPED POLICY' that does not exist.
Build system:
- mk/prefix.mk hardcoded 13.2.0 in the limits.h removal, which silently
no-ops after a toolchain upgrade and leaves the conflicting header.
Version-globbed.
- Parameterized GCC_RECIPE so the from-source toolchain path is not
pinned to gcc13.
- The three cstdlib strtold seds were not idempotent -- the shipped GCC
13 toolchain carried that comment block 17 times from repeated
'make prefix' runs. Each is now guarded.
The gitlink referenced 4398964, the tip of a stray 'bump-0.1.19' branch.
That branch violated local/AGENTS.md BRANCH AND SUBMODULE POLICY (no
version-named branches) and, being a wholesale replacement of the fork
with upstream, had dropped committed Red Bear work: the redox_syscall-
gated 'pub mod acpi' re-export, F_DUPFD_CLOEXEC, the vasilito authors
entry required by 'Fork authorship attribution', and the
gitea.redbearos.org repository URL required by the Single-Repo Rule.
submodule/libredox now carries upstream 0.1.19 merged into the fork, so
both the upstream multiple-fds work and all Red Bear work are present.
Type-checks clean for x86_64-unknown-redox.
GCC 13.2.0 defaulted to gnu17 (__STDC_VERSION__ 201710L); GCC 16.1.0
defaults to gnu23 (202311L). The recipe tree is C17-era code, and C23
turns an empty parameter list from 'unspecified arguments' into 'no
arguments', which is a hard error against a real prototype.
Pin the cookbook's default C dialect to gnu17. This states the dialect
these sources were written against rather than suppressing a diagnostic,
and matches how the distributions handled the same GCC 14/15 transition.
Packages migrate to C23 as they are touched; the pin is dropped when the
tree is clean. A per-recipe -std= still wins, being appended after. C++
is deliberately NOT pinned -- kwin needs C++23, which is the entire point
of the GCC 16 upgrade.
Fix a real cookbook bug this exposed: CMAKE_CXX_FLAGS was built from
CFLAGS, so the C dialect flag reached the C++ compiler and g++ reported
"'-std=gnu17' is valid for C/ObjC but not for C++" on every file. The
meson path already keeps c_args/cpp_args apart; CMake now matches.
CPPFLAGS still reaches both, which is what carries the sysroot includes.
First opportunistic C23 fix: libiconv's lib/loop_wchar.h declared
'extern size_t mbrtowc ();', conflicting with relibc's four-argument
prototype. That declaration exists only for platforms whose <wchar.h>
does not declare mbrtowc -- per its own comment, BeOS, which lacks
mbstate_t and #defines it -- and the very next line already tests
'#ifdef mbstate_t'. Moving it inside that guard keeps it where it is
needed and drops it where a real prototype is in scope.
libiconv now cooks clean against GCC 16.1.0.
The Redox target port applier claimed validation on 16.1.0 but its
idempotency probe used each block's longest line, which for three blocks
is generic upstream boilerplate. Against a pristine 16.1.0 tree that
silently skipped the libgcc target arms and BOTH crossconfig.m4 arms
(libgcc/config.host and crossconfig.m4 contain zero redox references, yet
the applier reported 'already present'), producing a half-ported tree --
the exact failure the script documents itself as preventing. Probe on the
longest redox-bearing line instead, matched whole.
Two port requirements the original extraction missed, both fatal:
- gcc/config/redox.opt.urls. GCC 16 requires a .opt.urls companion for
every .opt; s-options fails without it. Contents match what
regenerate-opt-urls.py emits for these two options, cross-checked
against the six upstream .opt.urls declaring the same pthread/rdynamic.
- libtool has no redox host. Upstream Redox gets shared libraries from
recipes/dev/libtool (a Redox-patched libtool 2.5.4-redox-9510) via
libtoolize during autoreconf, not from GCC's bundled libtool.m4. That
route does not apply to GCC 16, which bundles 2.2.7-era macros plus its
own ltgcc.m4. Without redox arms _LT_SYS_DYNAMIC_LINKER leaves
dynamic_linker=no, libstdc++ builds static-only, and the desktop stack
cannot link -- libQt6Core.so and every KF6 library carry DT_NEEDED
libstdc++.so.6. apply-libtool-redox.py registers the four arms that
matter, verbatim from the Redox libtool macros already in prefix/.
Result: x86_64-unknown-redox-gcc 16.1.0 with libstdc++.so.6.0.35 (SONAME
libstdc++.so.6, NEEDED libc.so.6 + libgcc_s.so.1 -- identical to the
13.2.0 library it replaces, exports a superset up to GLIBCXX_3.4.35).
std::ranges::to now compiles for the Redox target; GCC 13.2.0 fails the
same test, which is what blocked kwin's 16 affected files.
install-gcc16-toolchain.sh installs into all three locations a recipe can
resolve a compiler from -- including ~/.redoxer, which src/cook/script.rs
puts highest on PATH -- and is reversible with --restore. Its cstdlib
strtold patch is guarded; the mk/prefix.mk sed is not, and had applied
that block 17 times to the GCC 13 toolchain.
Both forks moved to the real upstream crate version, with in-house work
preserved deliberately rather than through upgrade-forks.sh's net-diff
(which squashes Red Bear commits into a single reapplied patch).
syscall 0.9.0 -> 0.9.1, via rebase. All 16 Red Bear commits replayed
individually so history and authorship survive; three obsolete label-only
commits dropped. Verified present afterwards: SYS_SETNS, SYS_CLOCK_SETTIME,
AcpiVerb::SetLpiHint, EnterS2Idle/ExitS2Idle, SetS3WakingVector, O_CLOEXEC,
SYS_SENDFD, SYS_OPENAT_WITH_FILTER, FullContextRegs, SYS_SYNCFS. Delta vs
upstream is purely additive: 348 insertions, 1 deletion across 9 files.
libredox 0.1.18 -> 0.1.19, via cherry-pick (a rebase aborted on the fork's
bulk "apply Red Bear patches" commit). Kept the two changes still unique to
us: demux() unwrap_or(u16::MAX) instead of .expect(), and Fd::ftruncate /
Fd::futimens taking &self. Dropped three in favour of upstream, which now
implements them at least as well: O_CLOEXEC handling, .gitignore/metadata,
and the bulk patch commit. Net delta is now 8 insertions / 3 deletions.
Pre-bump states kept at rb-backup/syscall-pre-0.9.1 and
rb-backup/libredox-pre-0.1.19 in the respective forks.
NOTE: neither fork branch is pushed yet - both rebases rewrote history, so
submodule/syscall and submodule/libredox need a force push, and the remote
tips must be confirmed to still equal the rb-backup commits first.
Applies the extracted port to an unpacked GCC tree: copies the 5
Redox-owned files, then inserts each redox arm at an anchored point.
Validated against a real gcc-16.1.0 tree (blake3
5f001609f662143ce9285cd740bd0acfeeaf7f13731b46fd1d9ebe620c5c340d).
Findings from that validation:
- GCC 16 already recognises redox in config.sub upstream, one fewer file
to patch than in 13.2.0.
- Two anchors moved since 13.2.0 and were re-derived: solaris folded into
the linux arm in crossconfig.m4, and the mingw32 targets were
consolidated in mkfixinc.sh.
- libgcc's riscv64 arm had been truncated during the original capture;
restored.
Two idempotency bugs found by comparing redox-line counts against the
13.2.0 reference rather than trusting "it ran clean":
- a substring probe matched the generic block's case label inside the
already-inserted aarch64/riscv64 label, silently skipping the second
crossconfig.m4 block;
- a first-line probe matched the aarch64 label inside CONFIG_GCC_OS,
silently skipping config.gcc's tm_file target arms, which would have
produced a tree that configures but never pulls in redox.h.
Now probes on the block's longest line, matched whole. config.gcc reaches
16/16 redox lines, matching the 13.2.0 reference exactly.
Verified for x86_64-unknown-redox: config.gcc tm_file arm incl. redox.h,
config.host xm_file, libgcc arm, crossconfig generic arm, mkfixinc arm,
gcc/config/redox.h, and the _GLIBCXX_USE_WEAK_REF define.
Re-running is a no-op. NOT YET BUILT: no compiler has been produced, and
gcc/configure plus libstdc++-v3/configure still need regenerating from
crossconfig.m4 with autoconf.
Latest upstream RELEASE tag is releases/gcc-16.1.0; '16.1.1' seen on distros
is a packaging/snapshot string, not an upstream release. Both
gcc-16.1.0.tar.xz and gcc-15.3.0.tar.xz confirmed reachable on ftp.gnu.org
(HTTP 206 on a range request). The Redox gcc fork carries no upstream
release tags, so the pristine base must come from ftp.gnu.org or
gcc-mirror.
Records the ordered next steps and marks them explicitly NOT STARTED, so the
extraction is not mistaken for a working port. The dominant cost is step 5 --
the full C++ tree rebuild forced by the libstdc++ ABI change -- not the
13-file port itself.
Groundwork for moving off GCC 13.2.0. Upstream redox-os/gcc has only
redox, redox-8.2.0 and redox-13.2.0, so there is no GCC 14+ with Redox
support to consume -- the port has to be carried by us.
Forced by KDE: KWin (16 files) and plasma-workspace (1 file) use C++23
std::ranges::to and both declare CMAKE_CXX_STANDARD 23. Verified the
current toolchain cannot satisfy that: the fork's libstdc++ has no
__cpp_lib_ranges_to_container and gcc/BASE-VER is 13.2.0, so there is no
hidden 14-ness to exploit. Backporting the call sites was rejected as the
costlier path -- it recurs every KDE release and diverges from upstream
KDE, against 'adapt to upstream, never the reverse'.
Measured surface: the whole Redox port is 13 files. Five are Redox-owned
(redox.h 36 lines, redox.opt 27 lines, three xm-redox.h) and are captured
verbatim under files/. The other eight are *-*-redox* case arms in
config.sub, gcc/config.{gcc,host,build}, libgcc/config.host,
libstdc++-v3/crossconfig.m4, os_defines.h and fixincludes/mkfixinc.sh,
captured with context in registration-hunks.txt. This is a textbook GCC
target port, not a compiler fork.
README records the apply procedure and the measured risks: libstdc++ ABI
change forces a full C++ tree rebuild; mk/prefix.mk currently DOWNLOADS the
toolchain from static.redox-os.org, so building our own is a permanent
ownership cost; relibc's cbindgen headers have a documented history of
fighting GCC and a newer one may reopen it; and mk/prefix.mk hardcodes
'13.2.0' in a path that must be parameterized.
Note gcc/configure and libstdc++-v3/configure also match 'redox' but are
GENERATED -- regenerate from crossconfig.m4, do not hand-edit.
The upgrade decision compared the newest upstream git TAG against $base,
which callers pass as the fork's Cargo.toml CRATE version. For several
Redox crates those namespaces are unrelated, so the comparison was
meaningless:
relibc git tags 0.5.0 / 0.6.0, but Cargo.toml AT tag 0.6.0 is 0.1.0,
and our fork is 0.2.5 -> reported '0.2.5 -> 0.6.0 upgrade'
when upstream master is 0.2.5, i.e. ALREADY CURRENT
libredox newest tag is v0.1.13, but upstream master is 0.1.19
Not cosmetic: upgrade-forks.sh consumes the result as --to=<ref> and does
'git reset --hard <ref>' before reapplying Red Bear commits as a net diff.
Acting on the relibc answer would have reset the fork onto an unrelated
lineage and reapplied our commits against it.
These forks are Cargo path deps with [patch.crates-io] and our label is
<upstream-version>+rb<branch>, so the CRATE version is the upstream
identity Cargo must satisfy -- compare crate-to-crate. Tag scanning
remains as the fallback for forks with no readable Cargo.toml.
Report after the fix:
syscall 0.9.0 -> 0.9.1 upgrade (tag 0.9.1 also exists)
libredox 0.1.18 -> 0.1.19 upgrade (master only; no matching tag)
relibc 0.2.5 ok (was a false positive)
redoxfs / redox-scheme / userutils ok
Known gap, documented at the call site: a fork whose crate version has no
matching tag (libredox) will make upgrade-forks.sh --to=<version> fail
loudly rather than reset onto a wrong ref -- the safe outcome. Threading
the upstream branch ref through as the rebase target is follow-up work.
vasilito