gcc47

• Path: arch/adapted/gcc47
• 2026-07-15: build failure fixed, pkgrel 3 -> 2.1 (per this project’s adapted/ X.Y sub-versioning convention, see PKGREL_VS_PKGVER.md – initially bumped to a plain 4 in error, corrected by the user afterward; already published as 2.1). The 4 missing texinfo patches described below were never restored – instead, noticed package() already does rm -rf "${pkgdir}/usr/share/" right after install, so generated docs (infodir/mandir, both under /usr/share) never actually ship in the package regardless of whether makeinfo succeeds. Simplest fix: don’t generate docs at all rather than resurrect 4 missing patches for output that gets deleted anyway. Removed the 4 dangling patch references from source=()/md5sums=()/ sha256sums=()/prepare(), and added MAKEINFO=':' to the configure invocation in build()’s _conf array (a no-op instead of the real makeinfo).
• Also hit, separately: depends=() includes cloog, which only exists in this project’s own archlinuxaba repo, not official core/extra – so the plain extra-x86_64-build chroot (no private repo configured) can’t resolve it (error: target not found: cloog). Had to use scripts/archlinuxaba-x86_64-build instead (adds this project’s own repo to the chroot’s pacman.conf, see that script’s own header) – same reason repo_build.sh already uses it for x86_64 internally. If testing this package with a plain extra-x86_64-build by hand, remember it’ll fail for this reason alone, unrelated to any PKGBUILD bug.
• Test-built clean with scripts/archlinuxaba-x86_64-build (0 compiler errors; both gcc47 and gcc47-debug packages produced, ~10MB / 46MB). Built+signed+published to the private repo (x86_64).
• Symlink issue (see above) is now fixed – package() already contains the ln -s 'lib/libgcc_s.so.1' ".../${pkgver}/libgcc_s.so" fix as of 2026-08-17 (found already in place, presumably added in an intervening session not reflected here).

Superseded (kept for context – the fix above addressed this)

• Build failure during the 2026-07-07 “build all packages for x86_64” private-repo release pass (see repo_release_logs/adapted_gcc47.log).
• PKGBUILD’s source=() array (lines 25-31) lists four local texinfo patch files that prepare() applies with patch -Nup1 -i "${srcdir}/<name>": gcc.texi.49.patch, 0000-sourcebuild.texi-itemx.patch, 0001-tm.texi-end-deftypevr.patch, 0002-invoke.texi-tie.patch. None of these four files actually exist in the package directory – only gcc-4.7.4-gcc-15-compilation.patch (a different, present patch) and the downloaded gcc-4.7.4.tar.bz2 are there. makepkg fails immediately at source retrieval: gcc.texi.49.patch was not found in the build directory and is not a URL.
• This is a genuine defect in the tracked package tree (missing local source files), not a build-environment or toolchain issue, and not something introduced by this release pass. Needs the four patch files restored (from wherever they were originally generated – the comment above the patch block says gcc.texi.49.patch was hand-generated via diff -pNau5 gcc/doc/gcc.texi{,.49}, so it may need regenerating rather than recovering from history) before this package can build again.
• Not fixed as part of the mass build pass – flagging only, since PKGBUILD repair (regenerating/sourcing 4 missing patches) is out of scope for a build+sign+publish run.

2026-08-17: i686/pentium4 attempted, reverted to x86_64-only

• arch=() had i686 declared already (from before this session) but it had apparently never actually built/published – only x86_64 packages ever existed on the repo. Added pentium4 too and attempted a real build for both 32-bit arches for the first time.

• Both failed identically, deep in the stage1 bootstrap (all-stage1-target-libgcc / install-shared):

  rm: .../gcc-build/./gcc/libgcc_s.so.1: version `GCC_7.0.0' not found
    (required by /usr/lib/libstdc++.so)
  ln: .../gcc-build/./gcc/libgcc_s.so.1: version `GCC_7.0.0' not found
    (required by /usr/lib/libstdc++.so)
  

  The dynamic linker fails to even run rm/ln themselves mid-build: something in the build environment (likely LD_LIBRARY_PATH pollution from the stage1 build-tree search path, gcc47 being a vintage-2012 GCC self-hosting against this chroot’s much newer host libstdc++) makes those coreutils resolve against the freshly-built (ancient, GCC_7.0.0-lacking) stage1 libgcc_s.so.1 instead of the system one. x86_64 doesn’t hit this (works fine both historically and in this session at pkgrel 2.3).

• Not root-caused further (would need to trace exactly why the 32-bit build environment’s dynamic linker search order differs from x86_64’s for a self-referential build-tree .so) – reverted arch=() back to ('x86_64') only rather than chase a deep GCC-bootstrap/toolchain interaction bug, matching the project’s established “not every package is a good fit for 32-bit arch expansion” precedent (see feedback_local_install_rebuilds.md). pkgrel stayed 2.3 (x86_64 was already correctly published at that pkgrel before the revert, no rebuild needed). If revisited, start by checking whether LD_PRELOAD='/usr/lib/libstdc++.so' (already used in package()’s make install) also needs applying earlier, to build()’s bootstrap make invocation.

2026-08-20: proper root-cause fix attempted – real progress, but a genuine bootstrap ABI conflict blocks 32-bit

• Root-caused the actual mechanism precisely this round (previous entry’s LD_PRELOAD theory was a symptom description, not the real cause). gcc’s top-level Makefile.in has STAGE1_LDFLAGS = @stage1_ldflags@, substituted at ./configure time from --with-stage1-ldflags (a real, documented GCC configure option – see configure’s stage1_ldflags/poststage1_ldflags handling). Its default is empty – unlike poststage1_ldflags, which defaults to -static-libstdc++ -static-libgcc automatically for stage2/3 whenever --with-host-libstdcxx isn’t set. So stage1 host tools (cc1 etc) stay dynamically linked against libstdc++/libgcc by design, unless explicitly told not to.
• First attempt: passed STAGE1_LDFLAGS=... on the top-level make command line instead of via configure. Didn’t work – confirmed via ldd/file that cc1 stayed dynamically linked. Root cause: that variable only seeds HOST_EXPORTS’ LDFLAGS for the stage1 “gcc” subdirectory’s own recursive ./configure, and that subdirectory’s generated gcc-build/gcc/Makefile bakes its own LDFLAGS in at ITS configure time – a make-command-line override of the top-level variable doesn’t reliably reach that point.
• Real fix: pass --with-stage1-ldflags='-static-libstdc++ -static-libgcc' directly to the top-level ../configure invocation in build()’s _conf array (same mechanism poststage1_ldflags already uses). Confirmed this genuinely worked this time: inspected the leftover chroot build tree after a failed i686 build (/var/lib/archbuild/archlinuxaba-i686/build/build/gcc47/...) – gcc-build/gcc/Makefile has LDFLAGS = -static-libstdc++ -static-libgcc, and cc1 itself (file/ldd) no longer lists libstdc++.so.6 as a dynamic dependency at all. pkgrel 2.4 -> 2.5.
• This genuinely advanced the build – i686/pentium4 got much further (all the way to cross-building libstdc++-v3 target libraries) before hitting a different occurrence of the same underlying class of bug: building libstdc++-v3’s po/ translations (de.mo, fr.mo) runs the system’s real /usr/bin/msgfmt, itself dynamically linked against a modern libicuuc.so needing recent GLIBCXX_3.4.30/CXXABI_1.3.8/1.3.9 symbols – but by that point in the build, HOST_LIB_PATH/TARGET_LIB_PATH (exported into the dynamic linker search path for every recursive sub-make invocation, intentionally, so xgcc/cc1 can find their own not-yet-installed support libs) has the in-progress, ABI-incomplete build-tree libstdc++.so.6 ahead of the real system one, so msgfmt itself fails to even load. This one also broke x86_64, which had never hit it before (previously succeeded without ever reaching this translation-generation step in the same way). Fixed by adding --disable-nls – this package already strips /usr/share/ wholesale in package() (same reasoning as the pre-existing MAKEINFO=: doc skip), so there’s no reason to generate translations either. pkgrel 2.5 -> 2.6. x86_64 now builds and publishes cleanly again with both fixes applied (confirmed via a real rebuild+publish, pkgrel 2.6).
• i686/pentium4 still fail, at the original libgomp stage1-configure point, but the actual root cause is now precisely understood and is a genuine, structural conflict rather than a fixable flag:
  • cc1 (thanks to the stage1-ldflags fix) no longer needs libstdc++/libgcc directly.
  • But cc1 also dynamically links libgmpxx.so.4 (GMP’s C++ bindings, pulled in transitively because this package builds with --with-ppl --enable-cloog-backend=isl, both PPL and CLooG using GMP’s C++ interface). libgmpxx.so.4 is a pre-built system library we don’t control, and it dynamically needs the real system libstdc++.so.6, which in turn needs libgcc_s.so.1 with the GCC_7.0.0 symbol version.
  • The freshly-built, in-progress libgcc_s.so.1 sitting in the build tree (built from gcc-4.7.4’s own, 2012-era libgcc sources) can never provide GCC_7.0.0 – that symbol-versioning scheme didn’t exist yet when 4.7’s libgcc sources were written. Since HOST_LIB_PATH puts the build-tree copy ahead of the real system one in the search path (by design, for cc1’s OWN needs), any OTHER, unrelated consumer that also needs “libgcc_s.so.1” (like system libgmpxx’s dependency chain) gets the wrong, incompatible one instead. There’s no way to make both consumers happy via search-order tricks alone – both need a shared object with the exact same soname, but genuinely different, incompatible symbol versions.
  • This is a known, somewhat inherent problem class when self-hosting/bootstrapping a ~decade-plus-old GCC using a very modern host toolchain. A prior maintainer evidently anticipated exactly this: build()’s _conf array has commented-out #CXX='g++-4.9' CC='gcc-4.9' and a commented-out #makedepends+=('gcc49') – i.e. the standard real fix is bootstrapping with an intermediate host compiler (old enough to not need GCC_7.0.0, new enough to compile 4.7.4’s own sources) instead of the chroot’s current system gcc. That would need gcc49 (or similar) built and published for i686/pentium4 too – a materially bigger undertaking, out of scope for this round.
  • Unclear why x86_64 doesn’t hit this exact conflict too (same --with-ppl/CLooG flags, so presumably also links libgmpxx) – not investigated further; possibly the x86_64 chroot’s system toolchain/libstdc++ differs in some relevant way, or the specific configure check that fails first for libgomp happens not to exercise the same dependency chain there. Worth checking first if revisited.
• Reverted arch=() back to ('x86_64') only – matches the established “not every package is a good fit for 32-bit expansion” precedent (see feedback_local_install_rebuilds.md, trojita-qt5-git’s Qt5-private-API blocker for a similar precedent). pkgrel stayed 2.6 (x86_64 already correctly rebuilt/republished at that pkgrel with both real fixes before the revert – narrowing arch=() alone needs no further rebuild).
• Net result of this round: real, durable improvements shipped for x86_64 (--with-stage1-ldflags is more correct/robust regardless of 32-bit; --disable-nls fixed an actual x86_64 regression this investigation surfaced). 32-bit remains blocked on a well-understood, documented, but out-of-scope-for-now structural bootstrap conflict.