aurupdater

gcc47

Build times (auto-updated)

2026-09-25/26: full ARM rebuild attempt – aarch64 impossible, armv7h/armv6h hit a real cpp bug

pkgrel 2.6 -> 2.7 -> 2.8. Built the full [[osl]] -> [[cloog]] -> [[libisl]] dependency chain first (all now adapted/, all built for every new arch this pass added) specifically to unblock this.

aarch64 added then removed same pass – hard, permanent incompatibility, not a bug: GCC 4.7.4 (2013) has no AArch64 backend at all – AArch64 support was only ever added in GCC 4.8. Build fails immediately: *** Configuration aarch64-unknown-linux-gnu not supported. No fix exists short of patching in an entire target backend – don’t re-attempt aarch64 for this package again.

armv7h and armv6h both fail identically, later in the build (stage1 libgcc sub-configure): checking how to run the C preprocessor... /lib/cpp then configure: error: C preprocessor "/lib/cpp" fails sanity check. Confirmed directly on eurobuild5: /lib/cpp genuinely doesn’t exist (/usr/bin/cpp does) – these are modern merged-/usr Arch Linux ARM systems with no legacy /lib/cpp compat symlink, which this 2013-era autoconf/libgcc configure script’s CPP-detection fallback chain doesn’t account for. This happens well into the build (after hours of successful stage1 gcc/ compilation on both boards), not at the very start – so it’s specifically libgcc’s own, separate sub-configure that mishandles this, not the top-level one. Not fixed this pass (user chose to skip ARM for now rather than chase it) – likely fixable by explicitly passing CPP=/usr/bin/cpp (or ac_cv_prog_CPP) into libgcc’s stage1 configure environment if revisited, but unconfirmed.

x86_64/i686/pentium4: never actually reached a real compile this pass – all three repeatedly hit the unrelated recurring 32-bit- chroot pacman-install hang (see memory/cloog.md’s 2026-09-25 entries and memory/TOOLING_NOTES.md) before even starting the actual GCC build. Still need a clean retry once that infrastructure flakiness is worked around (kill-and-retry, as documented there).

Current arch=(): x86_64 i686 pentium4 armv7h armv6h – aarch64 permanently excluded, armv7h/armv6h declared-but-unbuilt (a real, known gap – OVERVIEW.md will show ❌ for both until the /lib/cpp issue is actually fixed).

2026-09-26/27: i686/pentium4 fixed for real – GCC_7.0.0 symbol mismatch, root-caused and solved

pkgrel 2.8 -> 2.9 -> 2.10. x86_64/i686/pentium4 all publish cleanly now (4.7.4-2.10). The earlier “unrelated chroot hang” entry above turned out to be a real but separate infra issue (see memory/cloog.md) – once that stopped recurring, i686/pentium4 hit a second, genuine bootstrap bug of their own, now fixed.

Root cause (confirmed via ldd/config.log, not guessed): stage1 target-library sub-configures (configure-stage1-target-libgcc on ARM, configure-stage1-target-libgomp on i686/pentium4) invoke cc1 via NORMAL_TARGET_EXPORTS, which sets LD_LIBRARY_PATH from HOST_LIB_PATH – prepending the build tree’s own just-built, ABI-incomplete ./gcc/libgcc_s.so.1 ahead of the system one. cc1 itself is dynamically linked (confirmed --with-stage1-ldflags ='-static-libstdc++ -static-libgcc', already in this PKGBUILD, does NOT actually make it static – verified with ldd/file on the real built binary) and needs the system’s libstdc++.so.6, which on this host’s i686/pentium4 chroots requires GCC_7.0.0-versioned symbols (a symbol version introduced ~GCC 7, i.e. impossible for a 4.7-era libgcc_s.so.1 to ever provide) – cc1: .../gcc/libgcc_s.so.1: version 'GCC_7.0.0' not found (required by /usr/lib/libstdc++.so.6). x86_64 never hit this because its own system libstdc++.so.6 tops out at GCC_4.3.0 (confirmed via objdump -T), so the ABI mismatch never occurs there regardless.

Fix, in build(): a background loop, started right before nice make -s and running for its entire duration, continuously replaces gcc/libgcc_s.so.1 with a symlink to the chroot’s own complete system /usr/lib/libgcc_s.so.1 (a strict ABI superset – every old symbol a 4.7-era binary needs, plus whatever newer ones the system’s own libstdc++.so.6 needs) every time it sees that path as a real file newer than a marker touched at build() start. Purely a bootstrap-internal substitution: stage2+ never touches this file at all (its own cc1 genuinely is static, via POSTSTAGE1_LDFLAGS’s working default), and the final packaged libgcc_s.so.1 always comes from the last completed stage’s own install, never from stage1’s copy.

Two dead ends on the way there, both instructive:

Second, smaller bug surfaced once the real one was fixed: package()’s mv .../lib* (meant to relocate libgcc_s.so/.so.1 into a nested lib/ subdir before re-symlinking a top-level dev link) is a no-op on i686/pentium4 – confirmed via tar -tf on the published x86_64 package vs the raw pkgdir tree on i686 that the glob genuinely matches something and creates a real nested .../lib/ subdir on x86_64, but never does on i686/pentium4 (gcc’s own vanilla make install already places libgcc_s.so/.so.1 flat, directly at the top level, for those). The subsequent unconditional ln -s 'lib/libgcc_s.so.1' ... therefore either collided with the already-correct original (plain ln -s, no -f – caught this) or, had -f been added blindly instead of investigating, would have silently replaced a working real symlink with a dangling one pointing at a nonexistent lib/ subdir. Fixed by guarding the re-symlink with [ -d .../lib ] – only restore it when the mv actually had something to move in the first place.

Remaining gap: armv7h/armv6h still fail on the separate /lib/cpp issue documented above (untested this pass too – the ARM cluster [eurobuild4/5/14 + their NBD server eurobuild3] was down the whole time, confirmed unreachable via ssh).