riscv32-elf-gcc / riscv32-elf-newlib

• Paths: arch/maintained/riscv32-elf-gcc, arch/maintained/riscv32-elf-newlib
• Both are genuinely AUR packages maintained by andreas_baumann (confirmed via AUR RPC info – not third-party forks), so they’re ours to keep working.

2026-07-07: circular dependency identified, not fixed

Build failure during the “build all packages for x86_64” private-repo release pass. Mutually circular: riscv32-elf-gcc needs riscv32-elf-newlib and vice versa (error: target not found: riscv32-elf-newlib / error: target not found: riscv32-elf-gcc). Neither resolves in a single top-to-bottom alphabetical pass – classic cross-toolchain bootstrap problem (libc needs the compiler to build itself, the compiler needs libc headers to target the platform).

2026-07-22: resolved – published existing bootstrap artifacts, no PKGBUILD changes

The cycle was already solved by upstream (Filipe Laíns): riscv32-elf-gcc’s package dir ships a second recipe, PKGBUILD.bootstrap (pkgname=riscv32-elf-gcc-bootstrap), which builds a stage-1 compiler with --without-headers/C-only/inhibit-libc=true (no newlib needed), and provides=/conflicts= the real riscv32-elf-gcc so it can stand in for it as a build dependency. The correct sequence is:

1. Build+publish riscv32-elf-gcc-bootstrap (from PKGBUILD.bootstrap) – satisfies riscv32-elf-newlib’s makedepends=(riscv32-elf-gcc) via its provides=.
2. Build+publish riscv32-elf-newlib – now resolves.
3. Build+publish riscv32-elf-gcc (full) – its makedepends=(... riscv32-elf-newlib) now resolves too.

Two more things had to line up before this could actually run:

• riscv32-elf-binutils (a hard depends= of both gcc variants) isn’t an AUR package at all – it’s an official extra repo package (confirmed via pacman -Si riscv32-elf-binutils -> Repository: extra, packaged by Antonio Rojas). Nothing to build or maintain for it; the build chroot already has [extra] configured, so it resolves automatically. This is the “not ours to maintain” case – don’t go looking for a PKGBUILD for it anywhere in this tree.
• PKGBUILD.bootstrap’s makedepends=(gcc9 ...) hardcodes CC=gcc-9/CXX=g++-9 (gcc 9.3.0’s source doesn’t build cleanly with a much newer host compiler). gcc9 is itself only an AUR package (not in extra/archlinuxaba), so a fresh chroot build of the bootstrap stage would need gcc9 published to the private repo first too. Didn’t need to solve this – see below.

What actually happened, no rebuild needed: /data/INSTALL/riscv32-elf-gcc-bootstrap, /data/INSTALL/riscv32-elf-newlib, /data/INSTALL/riscv32-elf-gcc already contained working .pkg.tar.zst files from a manual bootstrap run on 2026-01-25 (outside the git-tracked repo_build.sh pipeline, hence never published to the private repo). Diffed their PKGBUILD/PKGBUILD.bootstrap against the current arch/maintained/ copies – byte-identical, so those artifacts are current, not stale. Copied them to a scratch dir (left /data/INSTALL untouched), signed with scripts/repo_sign.sh, and published with scripts/repo_publish.sh in the bootstrap -> newlib -> gcc order above. All three now resolve cleanly in the private repo (pacman -Si riscv32-elf-gcc shows Depends On: riscv32-elf-binutils zlib libmpc, all satisfiable).

No PKGBUILD content was changed anywhere in this tree – the existing PKGBUILD.bootstrap was correct as-is; the only “fix” was build/publish sequencing plus recognizing that riscv32-elf-binutils needed no action (official repo) and that already-built artifacts existed and matched current source.

If riscv32-elf-gcc or riscv32-elf-newlib ever need a version bump, the whole 3-stage sequence has to be redone from scratch (the bootstrap compiler would need a real chroot build then, hitting the gcc9-in-chroot gap above) – worth publishing gcc9 to the private repo before that happens, or revisiting whether PKGBUILD.bootstrap still needs a pinned old host compiler by then.