Akadata Limited
Get in Touch

Made in England · Saphira Linux · Version 0 Saphira

Toolchain and staging

The accepted five-stage build architecture and the actual Stage4 dependency order.

Saphira, the Saphira Linux Version 0 mascot
Technical preview

Current generation loop

The Forge built Saphira; Egg, Hatchling and Hatched prove the next turn

The five-stage pipeline below records the Forge that produced the first Saphira system. Current package work is deliberately a separate loop: Egg builds, Hatchling validates packages and boot behaviour, and Hatched stress-tests the assembled system. Findings return to Egg for a corrected build and another test run.

That loop feeds both the OpenRC Saphira path and the systemd Saphira-D path. Spawn of Saphira—the self-hosting stage with complete tooling and a proper installer—is in progress, not declared finished.

Read the full Saphira story

Five-stage distribution pipeline

One dependency chain, five explicit ownership boundaries

Stage0Cross SDK toolchain initialization

Builds binutils, patched GCC, and musl for x86_64-akadata-linux-musl, then passes an explicit acceptance gate.

Stage1Bootstrap rootfs generation

Creates the first musl rootfs from the glibc host while retaining builder ownership of source and build trees.

Stage2Native final system and GRUB

Builds the native final rootfs, validates the non-usrmerged FHS layout, and prepares native boot capability.

Stage3Bootable image assembly

Assembles and validates the base qcow2 image without turning the image step into a package build.

Stage4Managed server packages

Builds the Saphira APK repository and a derived server image containing packages such as Nginx, PHP-FPM, Python 3.14.6, OpenSSH, curl, and Vim.

Optional compiler policy

GCC 52cd026 generic branch-cost backport

Saphira can optionally build GCC 16.1 with the pinned backport of upstream commit 52cd02606b906160bf47001a00b446c35d46f15f. The patch changes one x86 generic-tuning value in gcc/config/i386/x86-tune-costs.h: the branch-misprediction scale increases from COSTS_N_INSNS (2) to COSTS_N_INSNS (2) + 3.

The higher modelled cost gives GCC more reason to avoid a conditional branch when its optimizers determine that a safe branchless transformation is cheaper. Depending on the code and optimization pass, that may mean conditional moves, arithmetic or other straight-line forms. It does not force cmov, remove every branch, or change processor hardware.

Potential benefit

Reduce misprediction-sensitive stalls

Branch-heavy hot paths with unpredictable conditions may benefit because a misprediction can discard speculative work and refill the pipeline. A possible 10–20% gain is a benchmark target for favourable workloads, not a measured distribution-wide guarantee. Some programs may improve less, remain unchanged, or regress.

Controlled experiment

Off by default and fully fingerprinted

The setting defaults to off. Its state and the patch SHA-256 are compile-policy inputs, so changing the toggle invalidates SDK through Stage4 evidence instead of mixing binaries produced under different compiler policies.

How the policy reaches the distribution

SDK construction applies the patch to a disposable generated GCC source tree and leaves the pristine GCC 16.1 source untouched. Stage1 applies and verifies the same policy in its native GCC. That native compiler then carries the selected cost model into downstream Stage2 and Stage4 compilation. Manifests record the enabled state, commit, and patch digest.

./build.sh settings show
./build.sh settings set gcc-branch-cost on
./build.sh rebuild all

# Return to the upstream GCC 16.1 cost model:
./build.sh settings set gcc-branch-cost off
./build.sh rebuild all

Use matched on/off images, identical inputs, repeated measurements, hardware performance counters, and workload-specific latency and throughput data before publishing a performance result. Enabling the option requires ./build.sh rebuild all; a partial build would not be valid comparison evidence.

Repair toolchain

Self-hosting toolchain APKs

The akadata-stage4-repair-toolchain profile builds a self-contained set of toolchain APKs so the distribution can be rebuilt or repaired from the running system without the cross SDK: zstd, gmp, mpfr, mpc, isl, readline, bash, coreutils, binutils, and gcc. Each also ships its -dev and -doc splits. Dependency order follows the acyclic graph: gmp → mpfr → mpc and gmp → isl; ncurses → readline → bash; zlib + zstd → binutils; binutils + zlib + zstd + gmp + mpfr + mpc + isl → the GCC variants.

The repair units are deliberately excluded from the default server profiles (base, network, server, build), so a normal Saphira image does not pull the toolchain in unless that profile is selected.

Canonical GCC

gcc-16.1.0-r0.apk installs under /usr and matches the base compiler. It applies the pure64 patch and the pinned upstream commit 52cd02606b906160bf47001a00b446c35d46f15f for the branch-cost backport described above.

Alternate GCC without the branch-cost patch

gcc-no-gcc-branch-cost-16.1.0-r0.apk builds the same GCC source but applies only the pure64 patch and omits the branch-cost backport. It installs isolated under /opt/akadata/toolchains/gcc-16.1-no-gcc-branch-cost and provides the launchers gcc-16.1-no-gcc-branch-cost and g++-16.1-no-gcc-branch-cost in /usr/bin. It coexists with the canonical GCC and is not selected by the repair profile; install it explicitly when a branch-cost-free baseline is required.

Deterministic Stage4 order

25 units from bootstrap APK to Vim

The generated order is numbered 00 through 24. It is derived from the acyclic dependency graph rather than maintained as a marketing-friendly shorter list.

  1. 00apk-bootstrap-static
  2. 01akadata-base-abi
  3. 02akadata-baselayout
  4. 03zlib
  5. 04zlib-dev
  6. 05openssl
  7. 06openssl-dev
  8. 07ca-certificates
  9. 08libcap
  10. 09libcap-dev
  11. 10libmnl
  12. 11libmnl-dev
  13. 12ncurses
  14. 13ncurses-dev
  15. 14python3
  16. 15ninja
  17. 16meson
  18. 17apk-tools
  19. 18iproute2
  20. 19iputils
  21. 20dhcpcd
  22. 21openssh-client
  23. 22openssh-server
  24. 23curl
  25. 24vim

The private bootstrap stays private

The disposable APK bootstrap builds its own zlib, OpenSSL, Python, Ninja, Meson, and static apk under build/stage4/work/apk-bootstrap. Its payload is neither copied into the deployment rootfs nor emitted as a Saphira package.

Package recipes then build in the derived Stage4 rootfs with sources mounted read-only and writable work directories mounted separately.