toolchain: remove the GCC 13 path; document the GCC 16 transition
redbear-ci / check (push) Has been cancelled

Operator decision 2026-08-05: "we will not have gcc 13." The cross
toolchain has been GCC 16.1.0 since the port landed, but the build system
still defaulted to GCC 13 in three places and nothing recorded the move.

Build system:
- mk/prefix.mk: GCC_RECIPE?=gcc13 -> gcc16.
- mk/prefix.mk: the HOSTED_REDOX package rule derives its names from
  $(GCC_RECIPE) instead of hardcoding gcc13.pkgar / gcc13.cxx.pkgar.
  static.redox-os.org publishes no gcc16 package, so that path now fails
  at download. Deliberate: a loud failure beats a wrong compiler.
- build-redbear.sh: refuse to build on a non-GCC-16 toolchain. This is
  the one that mattered on a Linux host. `make prefix` unpacks upstream's
  gcc-install.tar.gz, which IS GCC 13.2.0, and no make rule replaces it --
  GCC 16 arrives only via install-gcc16-toolchain.sh. A fresh prefix
  therefore put you silently back on GCC 13, surfacing ~40 minutes later
  as a kwin C++23 failure. The guard checks all three locations
  (gcc-install, sysroot, ~/.redoxer/<target>/toolchain -- the last has
  highest priority) and names the two scripts to run.

Docs:
- New local/docs/TOOLCHAIN-GCC16.md: why the move (kwin/plasma-workspace
  need std::ranges::to), build/install/rollback procedure, the three
  locations that must agree, the tree-wide -std=gnu17 and -fno-hardened
  consequences, and the open libstdc++ float16-formatter gap that
  currently blocks the kwin link.
- CHANGELOG, docs/README.md index and state summary, and the stale claim
  in NATIVE-TOOLCHAIN-WORKSTREAM.md that gcc13 "still builds the GCC 13
  cross toolchain".

Also corrects stale references found while auditing:
- AGENTS.md described prefix/ as "Clang/LLVM"; it is GCC 16.1.0 + LLVM + Rust.
- AGENTS.md cited local/reference/linux-7.0/ (tree is linux-7.1).
- AGENTS.md's durable-patching example cited a mesa patch that does not
  exist; replaced with one wired in recipe.toml. (The first replacement
  used patch 03, which the changelog records as orphaned -- it targets a
  file removed from Mesa 26.1.4 upstream.)

native_bootstrap.sh still installs gcc13/gcc13.cxx packages inside a
Redox VM. Left alone: that is the deferred gcc-native workstream and no
gcc16 package is published for Redox to point it at.

Verified: bash -n clean; make -n prefix parses; guard accepts the current
16.1.0 toolchain in all three locations and rejects a stubbed 13.2.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-05 10:11:06 +03:00
parent fddcc791b5
commit a287fe20b9
7 changed files with 304 additions and 13 deletions
+3 -3
View File
@@ -67,7 +67,7 @@ redox-master/
│ ├── scripts/ # Build/deploy scripts (fetch-firmware.sh, build-redbear.sh)
│ ├── docs/ # Red Bear integration docs (AMD roadmap, Wi-Fi/Bluetooth plans, status notes)
│ └── reference/ # External reference sources (gitignored, never deleted, always kept)
├── prefix/ # Cross-compiler toolchain (Clang/LLVM for x86_64-unknown-redox)
├── prefix/ # Cross-compiler toolchain for x86_64-unknown-redox (GCC 16.1.0 + Clang/LLVM + Rust)
├── build/ # Build outputs, logs, fstools, per-arch directories
├── repo/ # Package manifests and PKGAR artifacts per architecture
├── bin/ # Cross-tool wrappers (pkg-config, llvm-config per target)
@@ -385,7 +385,7 @@ See `local/docs/COLLISION-DETECTION-STATUS.md` for the current collision-detecti
## LINUX REFERENCE SOURCE POLICY
`local/reference/linux-7.0/` (or later) contains a full Linux kernel source tree for
`local/reference/linux-7.1/` (or later) contains a full Linux kernel source tree for
cross-referencing driver behavior, hardware initialization sequences, register definitions,
and error handling patterns.
@@ -593,7 +593,7 @@ tracked configs, `local/docs/`, and `local/sources/*/` survive.
| What you edited | Durable location |
|---|---|
| `recipes/libs/mesa/source/src/mesa/drm.c` | `local/patches/mesa/01-fix-drm-paths.patch` + `recipe.toml` |
| `recipes/libs/mesa/source/src/gallium/drivers/virgl/virgl_screen.c` | `local/patches/mesa/01-virgl-redox-disk-cache.patch` + `recipe.toml` |
| `recipes/wip/wayland/libwayland/source/src/wayland-client.c` | `local/patches/libwayland/redox.patch` + `recipe.toml` |
| `recipes/system/dbus/source/...` | `local/patches/dbus/dbus-root-uid.patch` + `recipe.toml` |
+50
View File
@@ -6,6 +6,56 @@ When a commit changes the visible system surface, supported hardware, build flow
or major documentation status, add a short note here and keep the README "What's New" section in
sync with the newest highlights.
## 2026-08-05 — Cross toolchain moved to GCC 16.1.0
### Build flow
- **Cross compiler is now GCC 16.1.0**, replacing the prebuilt GCC 13.2.0 that
Redox upstream ships from `static.redox-os.org`. Red Bear's own Redox target
port; upstream Redox has only ever shipped GCC 8.2.0 and 13.2.0.
- **Why:** kwin and plasma-workspace both declare `CMAKE_CXX_STANDARD 23` and
use `std::ranges::to`, which GCC 13.2.0 does not have. There is no route to a
Plasma desktop on the old compiler.
- **Built by two standalone scripts**, not the cookbook:
`local/scripts/build-gcc16-cross.sh` then
`local/scripts/install-gcc16-toolchain.sh`. The cookbook's from-source GCC
path is dead in this fork (it copies a `stage.cxx/` directory that nothing in
`src/` produces). Rollback via `--restore` from `build/gcc13-backup/`.
- **No GCC 13 fallback anywhere in the build** (operator decision, 2026-08-05).
`mk/prefix.mk` now defaults to `GCC_RECIPE?=gcc16` and derives its
Redox-hosted package names from that variable instead of hardcoding
`gcc13.pkgar`. `static.redox-os.org` publishes no gcc16 package, so that path
fails at download rather than seeding the wrong compiler.
- **`build-redbear.sh` refuses to build on a non-GCC-16 toolchain.** `make
prefix` unpacks upstream's `gcc-install.tar.gz` (GCC 13.2.0) and no make rule
replaces it, so a fresh prefix used to leave you on GCC 13 until the failure
surfaced ~40 minutes later inside kwin. The guard checks `gcc-install/`,
`sysroot/`, and `~/.redoxer/<target>/toolchain/`, and names the two scripts
to run.
### Tree-wide compile flags
- **C dialect pinned to `-std=gnu17`** (`src/cook/script.rs`). GCC 16 defaults
to gnu23, which makes an empty parameter list mean "no arguments" instead of
"unspecified" — libiconv's `extern size_t mbrtowc ();` then conflicts with
relibc's real prototype. C++ is deliberately not pinned.
- **`-fno-hardened` forced.** `-fhardened` is a host-glibc bundle this target
cannot implement, but GCC accepts it on the command line, so meson's
`cc.has_argument()` probe answers YES and then the compile fails for real.
seatd died on this 24 times.
### Known gap
- libstdc++ 16.1.0 as built here defines **zero** `std::formatter<_Float16>` /
`std::formatter<std::bfloat16_t>` specializations while `<format>` emits
`extern template` declarations promising them. This blocks the kwin link.
### Documentation
- **New `local/docs/TOOLCHAIN-GCC16.md`** — the transition record: versions,
build/install/rollback procedure, the three toolchain locations that must
agree, and the open libstdc++ gap.
## 2026-07-24 — 3D driver plan: comprehensive Mesa + virgl + Intel (PTL) + AMD assessment
### Documentation
+3 -1
View File
@@ -91,8 +91,9 @@ Do not flatten those into one “supported” claim in public summaries.
- `../local/docs/SCRIPT-BEHAVIOR-MATRIX.md` — what the main sync/fetch/apply/build scripts do and do not guarantee
- `../local/docs/FORK-BUMP-PATCHING-POLICY.md` — delicate patching during a version or toolchain bump (a bump is a rebase, never a replacement)
- `../local/docs/NATIVE-TOOLCHAIN-WORKSTREAM.md` — gcc-native/rust-native: deferred workstream, findings and re-enable procedure
- `../local/docs/TOOLCHAIN-GCC16.md` — the cross toolchain: GCC 13.2.0 → 16.1.0, why, how it is built/installed/rolled back, and the tree-wide `-std=gnu17` / `-fno-hardened` consequences
## Current State Summary (as of 2026-07-18)
## Current State Summary (as of 2026-07-18; toolchain line updated 2026-08-05)
This summary is only a quick orientation layer. For canonical current-state detail, see `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v6.0).
@@ -101,6 +102,7 @@ This summary is only a quick orientation layer. For canonical current-state deta
- `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` for support-language by tracked profile,
- and the active subsystem plans under `local/docs/` for detailed current workstreams.
- **Cross toolchain**: GCC **16.1.0** (Red Bear's own Redox port), replacing the upstream prebuilt GCC 13.2.0. Required for C++23 `std::ranges::to`, which kwin and plasma-workspace both need. See `local/docs/TOOLCHAIN-GCC16.md`.
- **Compile targets**: the supported compile targets are `redbear-mini`, `redbear-full`, and `redbear-grub`
- **Live ISO policy**: live `.iso` outputs (`build-redbear.sh`) are for real bare-metal boot/install/recovery workflows, not the VM/QEMU execution surface.
- **Wayland**: libwayland + wayland-protocols built. A bounded greeter/compositor-backed login proof now passes, but broader compositor/runtime stability remains incomplete.
+5 -2
View File
@@ -73,8 +73,11 @@ in gimple_build_eh_must_not_throw
```
An ICE is where flag-tweaking stops being a legitimate answer. Those three
fixes remain in `recipes/dev/gcc13/recipe.toml` — that recipe still builds the
GCC 13 cross toolchain and they are correct there.
fixes remain in `recipes/dev/gcc13/recipe.toml`, where they are correct for
that recipe. Note that the recipe no longer builds anything: as of 2026-08-05
this fork has **no GCC 13 path at all**`mk/prefix.mk` defaults to
`GCC_RECIPE?=gcc16` and `build-redbear.sh` refuses a non-GCC-16 toolchain. See
`TOOLCHAIN-GCC16.md`.
### After the move to GCC 16
+194
View File
@@ -0,0 +1,194 @@
# Cross Toolchain — GCC 13.2.0 → GCC 16.1.0
**Status:** DONE. The cross toolchain in `prefix/` is GCC 16.1.0 and is what
compiled every package in the current tree.
**Scope:** the **cross** toolchain (runs on the Linux host, targets
`x86_64-unknown-redox`). The **native** toolchain — a compiler that runs *on*
Redox — is a separate, explicitly deferred workstream; see
`NATIVE-TOOLCHAIN-WORKSTREAM.md`.
Related: `local/patches/gcc-redox-port/README.md` (the Redox target port
itself), `FORK-BUMP-PATCHING-POLICY.md` (a bump is a rebase, never a
replacement), `BUILD-SYSTEM-INVARIANTS.md`.
---
## Why the move happened
kwin and plasma-workspace both declare `CMAKE_CXX_STANDARD 23` and both use
`std::ranges::to`. GCC 13.2.0 — the prebuilt compiler Redox upstream ships from
`static.redox-os.org` — does not have it (`'to' is not a member of
'std::ranges'`). There is no way to reach a KDE Plasma desktop on GCC 13, so
the compiler had to move. Upstream Redox has only ever shipped GCC 8.2.0 and
13.2.0; GCC 16 for this target is Red Bear's own port.
## What the toolchain is now
| | |
|---|---|
| Version | GCC 16.1.0 (`local/recipes/dev/gcc16/source/gcc/BASE-VER`) |
| Target | `x86_64-unknown-redox`, built on `x86_64-pc-linux-gnu` |
| Languages | c, c++, lto |
| libstdc++ | `libstdc++.so.6.0.35` |
| Source | `local/recipes/dev/gcc16/source` + `local/patches/gcc-redox-port/` |
| Replaces | GCC 13.2.0 (prebuilt, downloaded from `static.redox-os.org`) |
Verify:
```bash
prefix/x86_64-unknown-redox/gcc-install/bin/x86_64-unknown-redox-gcc --version
# x86_64-unknown-redox-gcc (GCC) 16.1.0
```
## How it is built and installed
Two scripts, run in order. Neither goes through the cookbook — see "What is
still on GCC 13" below for why.
```bash
# 1. Build (~40 min). Configure flags mirror the cross arm of
# recipes/dev/gcc13/recipe.toml, so the result is configured like the
# compiler it replaces. Output: build/gcc16-install/
local/scripts/build-gcc16-cross.sh
# 2. Install over GCC 13 in all three locations the build reads from.
local/scripts/install-gcc16-toolchain.sh
```
The build script refuses to start unless the Redox port is actually applied to
the source — it greps for a `redox` arm in both `gcc/config.gcc` and
`libstdc++-v3/configure`. Without that guard a missing port surfaces only at
the end of a 40-minute build, as a compiler with no Redox target.
To apply the port to a fresh GCC 16 source tree:
```bash
python3 local/patches/gcc-redox-port/apply-redox-port.py local/recipes/dev/gcc16/source
# then regenerate libstdc++-v3/configure with autoconf 2.69
```
### The three locations must agree
This is the part that bites. A compiler is read from three places, and the last
one wins:
1. `prefix/<target>/gcc-install/` — the GCC half of the prefix
2. `prefix/<target>/sysroot/` — the merged prefix (gcc + rust + clang)
3. `~/.redoxer/<target>/toolchain/`**highest priority**; `src/cook/script.rs`
prepends it to `PATH` last, so it wins over both prefix paths for every
recipe
Updating only the prefix leaves every recipe silently on GCC 13. Check all
three:
```bash
for d in prefix/x86_64-unknown-redox/gcc-install \
prefix/x86_64-unknown-redox/sysroot \
~/.redoxer/x86_64-unknown-redox/toolchain; do
"$d/bin/x86_64-unknown-redox-gcc" --version | head -1
done
# all three must print 16.1.0
```
### Rollback
`install-gcc16-toolchain.sh` moves the GCC 13 components aside to
`build/gcc13-backup/` rather than deleting them. `--restore` puts them back.
## Tree-wide consequences
Three changes in `src/cook/script.rs` were required by the version jump. All
three are deliberate and documented at the point of use.
**C dialect pinned to `gnu17`.** 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 previously-legal constructs into
hard errors — most notably an empty parameter list, which used to mean
"unspecified arguments" and now means "no arguments". libiconv's
`lib/loop_wchar.h` has `extern size_t mbrtowc ();`, which under C23 conflicts
with relibc's real four-argument prototype. The pin states the dialect these
sources were written against; it suppresses no diagnostic, and it is what the
distributions did for the same GCC 14/15 transition. Per-recipe `-std=` still
wins, being appended after. Packages migrate to C23 as they are touched; when
the tree is clean the pin can go.
**C++ is deliberately NOT pinned** — kwin and plasma-workspace need C++23,
which is the whole reason for the upgrade.
**`-fno-hardened` forced.** `-fhardened` is a host-glibc hardening bundle that
`x86_64-unknown-redox` cannot implement. GCC still *accepts* it on the command
line, so a meson `cc.has_argument('-fhardened')` probe answers YES, meson adds
it to every compile, and GCC then refuses it for real:
```
cc1: error: '-fhardened' not supported for this target [-Werror]
```
The diagnostic is tagged `[-Werror]`, not `[-Werror=hardened]` — it is an
unconditional warning, so `-Wno-hardened` does not silence it. The flag has to
be cancelled outright. seatd died on this 24 times. This weakens nothing:
the flag is inert on this target by construction.
**Implicit declarations are now fatal** (GCC 14+), which is why the cookbook
defines `HAVE_ALLOCA_H` — C sources with no configure step otherwise skip
`<alloca.h>` and fail on an implicit `alloca`.
## There is no GCC 13 fallback
Operator decision, 2026-08-05: *"we will not have gcc 13."* The build system
was migrated to match, so nothing defaults to, downloads, or silently seeds the
old compiler:
- `GCC_RECIPE?=gcc16` (`mk/prefix.mk:13`) — the from-source path targets the
GCC 16 recipe.
- The Redox-hosted (`HOSTED_REDOX=1`) package path derives its package names
from `$(GCC_RECIPE)` instead of hardcoding `gcc13.pkgar`
(`mk/prefix.mk:224`). `static.redox-os.org` publishes no `gcc16` package, so
that path now fails at download until Red Bear hosts its own. This is
deliberate: a loud failure beats a wrong compiler.
- **`build-redbear.sh` refuses to build on anything but GCC 16.** This is the
one that matters on a Linux host. `make prefix` unpacks upstream's
`gcc-install.tar.gz`, which *is* GCC 13.2.0, and no make rule replaces it —
the GCC 16 compiler arrives only via `install-gcc16-toolchain.sh`. Before the
guard, a fresh `make prefix` left you on GCC 13 and the mistake surfaced
~40 minutes later as a kwin C++23 failure. The guard checks all three
locations and prints the two commands to run.
The cookbook's from-source path is **dead in this fork** regardless: it copies
`$(GCC_TARGET)/stage.cxx/usr/` and nothing in `src/` ever produces a
`stage.cxx` directory, so it cannot have run. Repairing it is separate work and
was not required to obtain a newer compiler — hence the two standalone scripts
above.
`recipes/dev/gcc13/` still exists on disk as an upstream-inherited recipe. It
builds nothing in this fork and is not on any path the build takes.
## Known open gap
libstdc++ 16.1.0 as built here is missing the float16 `std::formatter`
specializations. `<format>` sees `__FLT16_MAX__` from the cross compiler and
emits `extern template` declarations promising specializations the library does
not contain:
```
undefined reference to std::formatter<_Float16, char>::format<...>
undefined reference to std::formatter<std::bfloat16_t, char>::format<...>
```
Measured against the shipped library:
```bash
nm -D --defined-only prefix/x86_64-unknown-redox/sysroot/x86_64-unknown-redox/lib/libstdc++.so.6.0.35 \
| grep -c formatterIDF16 # 0 defined
nm -D -u prefix/x86_64-unknown-redox/sysroot/x86_64-unknown-redox/lib/libstdc++.so.6.0.35 \
| grep -c formatterIDF16 # 0 undefined
```
Zero either way — they are absent entirely, not merely unresolved. This blocks
the kwin link. The fix belongs on the libstdc++ side of the GCC 16 build
(enabling the float16 specializations when the target compiler advertises
`_Float16`), not in kwin: patching the consumer would mask a toolchain gap that
resurfaces for every C++23 package that formats a `_Float16`.
Itanium mangling reference, for grepping build logs: `DF16_` is `_Float16`,
`DF16b` is `std::bfloat16_t`.
+37 -1
View File
@@ -9,7 +9,7 @@ PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
# REDBEAR_VERSION (which tracks the OS release derived from the git branch).
# Starts at 1.0 and is bumped AUTOMATICALLY on every change by the pre-commit
# git hook (local/scripts/bump-build-version.sh); do not edit the minor by hand.
BUILD_REDBEAR_VERSION="1.12"
BUILD_REDBEAR_VERSION="1.13"
# ── Colorized output ──────────────────────────────────
# Enabled only on a TTY with NO_COLOR unset, so redirected build logs and CI
@@ -1074,6 +1074,42 @@ if [ "$STALE_PREFIX" = "1" ] && [ -z "${REDBEAR_SKIP_PREFIX_REBUILD:-}" ]; then
STALE_PREFIX=0
fi
# ── Toolchain guard: this fork is GCC 16 only ────────────────────────────────
# `make prefix` seeds gcc-install from upstream's static.redox-os.org tarball,
# which is GCC 13.2.0, and no make rule replaces it — the GCC 16 compiler is
# installed by local/scripts/install-gcc16-toolchain.sh. A GCC 13 toolchain
# compiles most of the tree and only fails deep into kwin, on the missing
# C++23 std::ranges::to, so it is far cheaper to refuse it here.
#
# All three locations are checked because the redoxer one has the highest
# priority (src/cook/script.rs prepends it to PATH last) and a mismatch
# between them is exactly how a "GCC 16" build silently uses GCC 13.
_rb_tc_target="${TARGET:-x86_64-unknown-redox}"
_rb_tc_bad=0
for _rb_tc_dir in \
"$PROJECT_ROOT/prefix/$_rb_tc_target/gcc-install" \
"$PROJECT_ROOT/prefix/$_rb_tc_target/sysroot" \
"$HOME/.redoxer/$_rb_tc_target/toolchain"; do
_rb_tc_cc="$_rb_tc_dir/bin/$_rb_tc_target-gcc"
[ -x "$_rb_tc_cc" ] || continue
_rb_tc_ver="$("$_rb_tc_cc" -dumpversion 2>/dev/null || echo unknown)"
case "$_rb_tc_ver" in
16.*) ;;
*)
echo "${C_ERR}>>> ERROR:${C_RESET} $_rb_tc_dir reports GCC $_rb_tc_ver; Red Bear requires GCC 16." >&2
_rb_tc_bad=1
;;
esac
done
if [ "$_rb_tc_bad" = "1" ]; then
echo "${C_ERR}>>>${C_RESET} Build and install the GCC 16 cross toolchain, then re-run:" >&2
echo " local/scripts/build-gcc16-cross.sh" >&2
echo " local/scripts/install-gcc16-toolchain.sh" >&2
echo " See local/docs/TOOLCHAIN-GCC16.md." >&2
exit 1
fi
unset _rb_tc_target _rb_tc_bad _rb_tc_dir _rb_tc_cc _rb_tc_ver
if [ "$NO_CACHE" = "1" ]; then
echo "${C_INFO}>>>${C_RESET} Cleaning repo and recipe caches for clean build..."
make repo_clean 2>/dev/null || true
+12 -6
View File
@@ -7,9 +7,10 @@ PREFIX_INSTALL=$(PREFIX)/sysroot/
PREFIX_PATH=$(ROOT)/$(PREFIX_INSTALL)/bin
BINUTILS_TARGET=recipes/dev/binutils-gdb/target/$(HOST_TARGET)/$(TARGET)
LIBTOOL_TARGET=recipes/dev/libtool/target/$(HOST_TARGET)
# Which GCC recipe the from-source toolchain path cooks. Override to move
# the toolchain to a new GCC (e.g. GCC_RECIPE=gcc16).
GCC_RECIPE?=gcc13
# Which GCC recipe the from-source toolchain path cooks. Red Bear's cross
# toolchain is GCC 16.1.0; there is no GCC 13 fallback in this fork. See
# local/docs/TOOLCHAIN-GCC16.md.
GCC_RECIPE?=gcc16
GCC_TARGET=recipes/dev/$(GCC_RECIPE)/target/$(HOST_TARGET)/$(TARGET)
LIBSTDCXX_TARGET=recipes/libs/libstdcxx-v3/target/$(TARGET)/$(HOST_TARGET)
RELIBC_FREESTANDING_TARGET=recipes/core/relibc/target/$(TARGET)/$(HOST_TARGET)
@@ -215,14 +216,19 @@ else
endif
$(PREFIX)/gcc-install: $(PREFIX)/gcc13.pkgar $(PREFIX)/gcc13.cxx.pkgar $(PREFIX)/libgcc.pkgar $(PREFIX)/libstdcxx.pkgar $(CONTAINER_TAG)
# Redox-hosted (HOSTED_REDOX=1) prefix. The package names follow GCC_RECIPE
# rather than being pinned to gcc13: this fork's toolchain is GCC 16 and must
# not silently seed a GCC 13 compiler. Note that static.redox-os.org publishes
# no gcc16 package, so this path fails at download until Red Bear hosts its
# own — deliberate, and a loud failure rather than a wrong compiler.
$(PREFIX)/gcc-install: $(PREFIX)/$(GCC_RECIPE).pkgar $(PREFIX)/$(GCC_RECIPE).cxx.pkgar $(PREFIX)/libgcc.pkgar $(PREFIX)/libstdcxx.pkgar $(CONTAINER_TAG)
ifeq ($(PODMAN_BUILD),1)
$(PODMAN_RUN) make $@
else
rm -rf "$@.partial" "$@"
mkdir -p "$@.partial"
pkgar extract --pkey $(PREFIX)/id_ed25519.pub.toml --archive "$(PREFIX)/gcc13.pkgar" "$@.partial"
pkgar extract --pkey $(PREFIX)/id_ed25519.pub.toml --archive "$(PREFIX)/gcc13.cxx.pkgar" "$@.partial"
pkgar extract --pkey $(PREFIX)/id_ed25519.pub.toml --archive "$(PREFIX)/$(GCC_RECIPE).pkgar" "$@.partial"
pkgar extract --pkey $(PREFIX)/id_ed25519.pub.toml --archive "$(PREFIX)/$(GCC_RECIPE).cxx.pkgar" "$@.partial"
pkgar extract --pkey $(PREFIX)/id_ed25519.pub.toml --archive "$(PREFIX)/libgcc.pkgar" "$@.partial"
pkgar extract --pkey $(PREFIX)/id_ed25519.pub.toml --archive "$(PREFIX)/libstdcxx.pkgar" "$@.partial"
mv "$@.partial/usr"/* "$@.partial"