plasma-desktop's CMakeLists.txt:223 does
find_package(XCB REQUIRED COMPONENTS XCB SHM IMAGE)
and configure aborted with "Could NOT find XCB (missing: XCB_LIBRARIES XCB SHM
IMAGE)" -- libxcb was promoted but plasma-desktop did not depend on it, so it
was absent from that recipe's sysroot.
libxcb supplies xcb and xcb-shm (libxcb-shm.a confirmed staged); IMAGE comes
from xcb-util-image, which needs xcb-util. Both promoted out of recipes/wip/x11
and their tarballs fetched and blake3-verified.
This is the case for xcb on Wayland, not X11 nostalgia: KDE's XWayland
integration and Qt's xcb platform plugin both reference these.
plasma-workspace now builds and installs, so plasma-desktop configured for the
first time and stopped at:
The following required packages were not found: - libwacom
kcms/tablet requires libwacom (CMakeLists.txt:175), which is not ported -- it
needs libgudev plus upstream's tablet-definition database. Disabled via
upstream's own option (CMakeLists.txt:44, default ON), not an invented switch;
it gates exactly three sources (tabletsmodel.cpp, kcmtablet.cpp,
tabletmoduledata.cpp) and nothing else in plasma-desktop is affected.
THIS REMOVES THE DRAWING-TABLET SETTINGS MODULE. Tracked as a real port; the
option goes back ON in the same change that lands libwacom.
plasma-workspace COMPILED AND LINKED COMPLETELY and then failed at install:
file INSTALL cannot copy ".../libnotificationmanager/plasmanotifyrc"
to "/etc/xdg/plasmanotifyrc": Permission denied
`cmake --install --prefix` re-roots only RELATIVE destinations. KDE's
KDE_INSTALL_FULL_* paths are absolute, so cmake tried to write into the BUILD
HOST's /etc -- only the host's permissions stopped it from polluting the host
filesystem. DESTDIR re-roots absolute destinations too. Same fix already
applied to kf6-ktexteditor, kde-cli-tools and sddm.
plasma-desktop gets the same fix pre-emptively: it ships /etc/xdg config and
has never been built, so this would otherwise have cost another full cycle.
54 other KDE recipes use the --prefix form but install nothing to an absolute
path, which is why they build clean; left alone rather than churned.
kcm_users failed with 'ld: cannot find -lcrypt' although libc.a exports crypt
and crypt_r. relibc now ships empty libcrypt.a/libutil.a so the link resolves
from libc, matching what it already does for libdl/libpthread/librt.
KWindowSystem ships fixx11h.h (X11 macro cleanup), netwm.h and netwm_def.h
(EWMH) only with its X11 component, so a Wayland-only install lacks them. They
carry no X11/ or xcb/ path prefix, so the prefix-only rule missed them:
logout-greeter/shutdowndlg.cpp:51: fatal error: fixx11h.h: No such file
The single remaining unguarded case is libtaskmanager/xwindowtasksmodel.cpp,
which upstream excludes from the build via if(HAVE_X11) in
libtaskmanager/CMakeLists.txt -- it is never compiled, so it is left alone
rather than edited for appearance.
Converting `#ifdef HAVE_X11` to `#if HAVE_X11` changes the question from "does
this macro exist" to "what is its value", so the definition must actually be in
scope. Doing the conversion without guaranteeing the include turned a silently
inert guard into a hard error:
shell/panelview.h:13: error: 'HAVE_X11' is not defined, evaluates to 0
KDE builds with -Werror=undef, so an undefined macro in #if is fatal. The
previous commit fixed the guard form and introduced this; the transform now
inserts #include <config-X11.h> when it converts a guard in a file that lacks
it.
Verified: panelview.h now carries the include, and a second run is a no-op.
libtaskmanager/virtualdesktopinfo.cpp defines namespace X11Info at namespace
scope in terms of QNativeInterface::QX11Application, which does not exist in a
Qt built without the xcb platform:
error: 'QX11Application' is not a member of 'QNativeInterface'
All three call sites were already inside #if HAVE_X11 -- only the definition
was exposed -- so wrapping the block changes no reachable behaviour.
Restricted to depth-0 'namespace' blocks whose body names an X11-only native
interface. Narrow on purpose: brace-matching arbitrary function definitions is
much easier to get wrong, and a bad transform here produces invalid C++ rather
than a clean failure.
Distinct from the KWindowSystem-API gating: these are the Xlib/XCB headers
themselves, which a Wayland-only sysroot does not ship, so each is a hard
compile failure rather than a lost feature:
appmenu/appmenu.h:13: fatal error: xcb/xcb.h: No such file or directory
Two of the affected directories are genuinely compiled and would have failed in
turn: kcms/kfontinst (gated only on FONTCONFIG_FOUND) and logout-greeter
(CMakeLists.txt:428, outside any X11 gate). kcms/cursortheme is already gated
upstream by `if(WITH_X11 AND X11_Xcursor_FOUND)` and ksmserver by if(WITH_X11);
guarding them too is harmless and keeps the rule uniform rather than
maintaining a list of exceptions.
Only touches includes at preprocessor depth 0 with respect to HAVE_X11, so
anything already guarded is left alone.
Verified: preprocessor balance OK across all 59 files carrying guards, and a
second run is a no-op (0 files, 0 includes) -- the recipe re-runs this on every
build, so idempotency is a correctness requirement, not a nicety.
config-X11.h.cmake declares the macro with `#cmakedefine01 HAVE_X11`, which
always DEFINES it -- as 0 when X11 is off, not undefined. So `#ifdef HAVE_X11`
is true in BOTH configurations and the guard does nothing:
#ifdef HAVE_X11
#include <xcb/xcb.h> <- compiled even with HAVE_X11 == 0
#endif
That is how appmenu.h reached
appmenu/appmenu.h:13:10: fatal error: xcb/xcb.h: No such file or directory
while looking correctly guarded. `#if HAVE_X11` reads the value and behaves as
intended.
An upstream bug invisible on any system that has X11 headers installed, because
there the include just succeeds. 3 occurrences across appmenu.h and
panelview.h; plasma-desktop has none. Normalisation runs on every file rather
than only those using the X11-only KWindowSystem APIs, since the defect is
about the guard form, not the guarded content.
-Wa,--noexecstack did not reach icudt75l_dat.o: ICU builds it through pkgdata,
which drives the assembler with its own flags and ignores CFLAGS. Verified
empirically -- after a full ICU rebuild readelf still showed 0 GNU-stack
sections, and plasma-workspace failed identically.
Patching the archive member is deterministic where the flag was not. The added
section is empty and read-only: it declares a non-executable stack, which is
exactly true for a pure data blob. Verified objcopy 0 -> 1 section on the real
archive before committing.
Without it, binutils warns "missing .note.GNU-stack section implies executable
stack", and KDE's ECM links with -Wl,--fatal-warnings, so every KDE consumer of
static ICU fails (plasma-workspace applets/digital-clock, ld exit 1).
Asserts the section is present afterwards rather than swallowing errors: a
silent no-op here resurfaces as a link failure in a different package, far from
the cause.
Both found by pre-checking plasma-desktop against the failure classes already
catalogued, before it was ever attempted -- rather than discovering them one
~15-minute build at a time.
1. KSMServerDBusInterface. plasma-desktop hard-requires it (CMakeLists.txt:191,
CONFIG REQUIRED), but upstream generates it in ksmserver/CMakeLists.txt and
add_subdirectory(ksmserver) sits inside if(WITH_X11) -- OFF here -- so a
Wayland-only build never installs it. Only the D-Bus INTERFACE is needed:
the XML is a platform-independent description and upstream's
KSMServerDBusInterfaceConfig.cmake.in is a single variable pointing at it.
ksmserver itself is X11-only (links X11::X11/SM/ICE and PW::KScreenLocker)
and stays unbuilt. XML copied verbatim from the upstream tree. Same shape and
same remedy as kscreenlocker.
KRunnerAppDBusInterface, also REQUIRED by plasma-desktop, needs nothing:
add_subdirectory(krunner) is outside the X11 gate.
2. X11-only KWindowSystem headers, reusing gate-kx11extras.py unchanged:
KX11Extras (4 files), KUserTimestamp (1), KWindowInfo (2).
Dry-run on the plasma-desktop tree: 3 files gated, 5 includes, 6 blocks;
preprocessor balance OK across all 5 files carrying guards; no malformed
'#endif <code>'; no unguarded references left. Source restored afterwards --
the recipe applies this at build time.
ICU emits its data as generated assembly (icudt75l_dat.S). Without
-Wa,--noexecstack the assembler produces an object with no .note.GNU-stack
section, and modern binutils warns:
ld: warning: icudt75l_dat.o: missing .note.GNU-stack section implies
executable stack
Harmless alone -- except KDE's ECM links with -Wl,--fatal-warnings, so every
KDE consumer of static ICU fails outright (first hit: plasma-workspace
applets/digital-clock, collect2: error: ld returned 1). Fixed at the source
rather than suppressed downstream, which would have to be repeated per consumer.
Also gates the '#'-inside-a-backslash-continuation trap, which terminates the
continuation and silently drops every remaining argument. It has now bitten
three times, most recently while writing THIS commit: the noexecstack rationale
was first placed between two continued configure flags, which would have
dropped the rest of ICU's configure line. Moved above the invocation.
The check scans the RAW file, not the parsed TOML. In a multi-line basic string
a trailing backslash is itself a TOML line-continuation escape, so the newline
is gone before the value is handed over and the parsed string has no trailing
backslashes at all. The first version scanned the parsed value and silently
found nothing -- caught by a self-test, not by review, which is the same class
of invisible failure the gate exists to prevent.
ICU is built static here (--enable-static --disable-shared, and
--with-data-packaging=static), so the data blob lives in libicudata.a. CMake's
builtin FindICU exposes ICU::uc and ICU::i18n but not ICU::data, and a static
archive carries no DT_NEEDED to pull the data in the way libicuuc.so would on a
normal system. The digital-clock plugin failed to link:
udata.cpp:(.text+0xea1): undefined reference to `icudt75_dat'
STANDARD_LIBRARIES rather than LINKER_FLAGS: the latter is emitted before the
object files, where a static archive contributes nothing. Same reasoning as the
-lgcc entry in redox-toolchain.cmake.
Scoped to this recipe rather than the shared toolchain: not every recipe using
that toolchain stages ICU, so a blanket -licudata would become "cannot find
-licudata" for them.
Two coupled problems, both restored by the `git checkout -- local/recipes/`
revert that undid this session's uncommitted recipe work.
1. A '#' comment block sat INSIDE the backslash-continued cmake invocation. A
comment line terminates the continuation, so every flag after it was silently
dropped -- SCREENLOCKER, TABBOX, GLOBALSHORTCUTS, RUNNERS and the rest took
cmake's defaults instead of the values written here. The recipe already
carries a NOTE warning about exactly this trap; the rationale text is now
above the invocation where it cannot truncate anything.
2. With the flag dropped, KWIN_BUILD_SCREENLOCKER defaulted ON, and kwin gates
find_package(KScreenLocker) on it (source/CMakeLists.txt:376), so configure
aborted:
The following REQUIRED packages have not been found:
* KScreenLocker For screenlocker integration in kwin_wayland
kscreenlocker ships only the ScreenSaverDBusInterface package; the library
still needs its Wayland-only port.
Set OFF explicitly. THIS MEANS THERE IS NO LOCK SCREEN -- documented at the flag
and in the kscreenlocker recipe. Turn it back ON in the same change that lands
the library port.
Verified: 0 comment lines remain inside the invocation.
QQmlEngine::networkAccessManager() exists only under QT_CONFIG(qml_network),
a qtdeclarative feature separate from QT_FEATURE_network, which was already ON.
kirigami failed on it:
src/primitives/icon.cpp:469: 'class QQmlEngine' has no member named
'networkAccessManager'
qtbase builds libQt6Network here, so enabling the feature restores kirigami's
remote icon loading instead of compiling the capability out.
This rewrite was lost when `git checkout -- local/recipes/` reverted every
uncommitted recipe edit, so the full-build version came back and the build tried
to compile the X11 locker on a Wayland-only target:
globalaccel.cpp:8 fatal error: KKeyServer
x11locker.h:15 fatal error: X11/Xlib.h
greeter/greeterapp.cpp:63 fatal error: X11/Xatom.h
plasma-workspace needs only ScreenSaverDBusInterface (CMakeLists.txt:127), used
in three qt_add_dbus_interface calls that generate a D-Bus client proxy from the
XML; it never links the library. The one consumer that does link
PW::KScreenLocker is ksmserver, which sits inside if(WITH_X11) and is not built.
The library port (~61 X11/XCB sites) and KWIN_BUILD_SCREENLOCKER remain open
work, documented in the recipe. Both installed files are verbatim upstream
artefacts -- nothing fabricated.
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.
vasilito