The relibc-consumer invalidation (correctly) force-deletes every pkgar+target
when relibc rebuilds or its pkgar is missing, to prevent stale-ABI skew. But it
swept up heavy, ABI-inert toolchain packages (llvm21, clang21, lld21, rust)
identically to a 200KB daemon — forcing a 1-2h LLVM re-cook on EVERY base/relibc
bump, which cripples Mesa/KDE iteration.
These are build-time-only STATIC archives (BUILD_SHARED_LIBS=off; no runtime .so
of their own). Their libc/relibc symbol references are UNRESOLVED in the .a and
resolve at the CONSUMER final link — mesa links libLLVM*.a and resolves against
the freshly-built relibc there. So a relibc protocol change is absorbed by
relinking mesa (NOT on the preserve-list; stays invalidated), and recompiling
all of LLVM from scratch is unnecessary.
Add TOOLCHAIN_PRESERVE={llvm21,clang21,lld21,rust} skipped in both invalidation
branches, with escape hatch REDBEAR_FORCE_TOOLCHAIN_RECOOK=1 for a genuine
libc-ABI change. Trades a rare theoretical risk for a large repeated speedup;
the churn during driver/desktop work is Redox scheme/syscall shims the compilers
never call, so the default is safe.
vasilito
f6b09ff713