aurupdater

slimcc-git

Build times (auto-updated)

Build times (auto-updated)

2026-09-28: arch=() extended to pentium4/i686/i486 – 32-bit archs fail in check(), x86_64-only by design

Found an uncommitted local PKGBUILD edit already staged (the user’s own change, upstream maintainer) when asked to “build and publish”: pkgrel 1->2, arch=(x86_64) -> arch=(x86_64 pentium4 i686 i486), plus a Maintainer-line email format tweak. Also cleaned a stale leftover slimcc-git-r921.ff77023-1-x86_64.pkg.tar.zst from /data/INSTALL (May 5, pre-dating this pkgrel bump) before building.

build() itself succeeds on all four archs – ln -s platform/linux-glibc-generic.c platform.c compiles fine everywhere. check() fails on pentium4/i686/i486 with error: gcc library path not found from every test invocation. Root-caused in platform/linux-glibc-generic.c’s platform_search_dirs(): gcclibpath = find_dir_w_file("/usr/lib*/gcc/x86_64*-linux*/*/crtbegin.o") is hardcoded to an x86_64 glob (also dumpmachine_str = "x86_64-linux-gnu" and the x86_64-only include/lib paths in platform_stdinc_paths/platform_search_dirs). On a 32-bit chroot gcc’s own crtbegin.o lives under a different triple (i686-pc-linux-gnu etc.), so the glob never matches and the freshly built slimcc can’t find a libgcc to link test binaries against – this fires the moment check() tries to actually run the compiler, not during build() itself. None of the project’s other platform/*.c variants (freebsd.c, linux-alpine.c, linux-musl-bootstrap.c, etc.) are 32-bit targets either – this isn’t a missing PKGBUILD wiring, the upstream project’s own pkgdesc (“for x86-64 Linux/BSD”) confirms it’s x86_64-only by design, same situation as chibicc-git’s i686 failure (see that package’s own memory entry).

x86_64 built+published cleanly (r1146.9778925-1, live pkgver bumped during build as expected for a -git package). pentium4/i686/i486 left unpublished – not attempted to fix (would mean either disabling check() on non-x86_64 or dropping those archs from arch=(), a real decision for the upstream maintainer, not a build-tooling problem). Flagged to the user rather than guessing.

Resolved same session: user chose to revert arch=() back to (x86_64) (matches upstream’s own x86-64-only scope) rather than skip check() or leave the 32-bit archs staged-but-failing. pkgrel stays at 2 per the user’s own call (already reflects the maintainer-email tweak too) – no rebuild needed, the published x86_64 package already matches. .SRCINFO regenerated to match.

2026-10-10: routine rebuild

Rebuilt r921.ff77023-2 -> r1156.374082f-1, built+published cleanly, x86_64. checkpkg warned “the built package is the one in the repo right now” (a non-fatal namcap/checkpkg note, not an error – publish proceeded normally).