gcc10

• Category: local-install (see arch/scripts/install_only_packages) — plain upstream AUR package (maintainer Chris Severance), not maintained/adapted by us. Built+published 2026-08-27 specifically to satisfy [[cmake2]]’s makedepends=('gcc10') for real (unlike [[gcc9]], which was published as a stopgap substitute first and hit its own unrelated build issue for that package).
• Had a real, previously-failed manual build attempt already sitting at /data/INSTALL/gcc10 (pkgrel 2, build log showed a genuine failure, no .pkg.tar.* ever produced) — picked up and fixed rather than starting over:
  • Root cause 1: libsanitizer failed to compile — fatal error: linux/scc.h: No such file or directory in libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp. linux/scc.h is an obsolete synchronous-serial-driver kernel header current linux-api-headers/glibc no longer ships (there were already two similar “obsolete kernel header” patches in this checkout for termio.h etc, from the same class of bit-rot — GCC 10.5 vs a modern kernel-headers/glibc combo). User’s call: skip building libsanitizer entirely (--disable-libsanitizer in build()’s _conf array) rather than patch out yet another missing header one at a time.
  • Root cause 2 (--disable-libsanitizer alone wasn’t enough): GCC 10.5’s split-package package_gcc10()/package_gcc10-libs() functions still had hardcoded make -C ".../libsanitizer" ... install calls and a libsanitizer/{a,l,ub,t}san entry in the libs array — those obviously fail once the dir was never built/ configured (make: *** .../libsanitizer: No such file or directory. Stop. — that exact phrasing is GNU Make’s own message for a make -C <missing-dir> invocation, not a shell cd failure). Removed all of it: the libsanitizer/{a,l,ub,t}san _libs array entry, the 4 make -C .../libsanitizer... install lines in package_gcc10(), and the lib{u,a,t}san.so/liblsan.so provides=() entries in package_gcc10-libs() (nothing left to provide those sonames once sanitizer libs aren’t built).
  • Confirms --disable-libsanitizer is not fully “clean” on this GCC branch/PKGBUILD combo — later GCC versions handle this more completely. If ever rebuilding a different old-GCC PKGBUILD with the same flag, check its package_*() functions for hardcoded libsanitizer references before assuming the configure flag alone is enough.
  • Kept pkgrel at 2 (matches the pre-existing failed-attempt checkout’s own numbering; first time this ever actually built and published, no prior successful version to bump past).
• x86_64 only (that’s all this checkout ever targeted).

2026-09-10: tried aarch64 (to unblock cmake2), hit a board OOM – reverted, staying x86_64-only

Attempted as a prerequisite for building [cmake2] on 64-bit archs. Added aarch64 to arch=(), pkgrel 2 -> 2.1 (real content change, local-install X.Y scheme). PKGBUILD itself turned out mostly portable already (the one CARCH-conditional bit is x86_64-specific multilib handling that harmlessly no-ops elsewhere; no other hardcoded arch assumptions) – emacs/tree-sitter were already available for aarch64 too (official repos).

First attempt failed immediately on gcc-10.5.0.tar.xz ... FAILED (unknown public key 3AB00996FC26A641) – no keys/pgp/ dir existed for this package yet. Confirmed via keyserver lookup that 3AB00996FC26A641 is a subkey of Richard Guenther’s key already in validpgpkeys (...6EEB81F8981C74C7), just never imported locally. Fixed by running update_pgp_key_dir.sh (populated keys/pgp/*.asc for all 4 validpgpkeys entries) – remote_build.sh auto-imports from there before building.

Second attempt got much further (past PGP, through configure, deep into stage1 bootstrap compiling insn-emit.c) but died with g++: fatal error: Killed signal terminated program cc1plus – eurobuild14’s kernel OOM-killer, confirmed directly via dmesg: Out of memory: Killed process (cc1plus) ... anon-rss:664444kB. The board has only 1.8GB RAM and zero swap configured (free -h: Mem: 1.8Gi ... Swap: 0B) – insn-emit.c is one of GCC’s most memory-hungry generated files to compile even on capable hardware, and this board just doesn’t have the headroom (no swap to fall back on when the working set spikes).

User’s call: not worth adding swap to the board or chasing this further – reverted aarch64 from arch=() and pkgrel back to 2, matching HEAD (the un-fixed-upstream commit) exactly for those two fields while leaving every other pre-existing uncommitted local fix (--disable-libsanitizer etc., from the original 2026-08-27 session, never committed per this project’s “never commit” policy) untouched. cmake2 stays x86_64-only too, for the same reason – see its own memory note. If aarch64 is ever revisited for this package, eurobuild14 needs a swapfile first (straightforward on its NBD-mounted /data volume, not local SD flash) – the PKGBUILD/keys side is otherwise ready.