aurupdater

lacc-git

Build times (auto-updated)

Category: local-install (rebuilt only so archlinuxaba/the cluster gets it too; not maintained/adapted/owned by us — see arch/scripts/install_only_packages). User (Andreas Baumann) is the upstream AUR maintainer.

A simple, self-hosting C compiler.

Build notes (2026-08-19)

2026-09-28: arch extended to i486/i686/pentium4, rebuilt+published

Found PKGBUILD already carrying an uncommitted local edit when asked to “rebuild and publish”: pkgrel 1 -> 2, arch=(x86_64) -> arch=(x86_64 i486 i686 pentium4) – the user’s own staged change (they’re lacc-git’s actual upstream AUR maintainer), so built as-is rather than questioning it.

The 2026-08-19 worry above (that --build=x86_64-linux being hardcoded would make 32-bit builds meaningless) was initially assumed not to apply, based on the i486/i686/pentium4 build logs showing compiler warnings with size_t resolving to unsigned int (i.e. lacc’s own build genuinely produced 32-bit executables). That check was insufficient and the 2026-08-19 note was right all along – see the correction below. All four archs built, check() “passed” (it’s a no-op: make: Nothing to be done for 'test'), and all four published, r1023.3083984-2, debug packages included.

2026-09-28 (same day, follow-up): i486/i686/pentium4 packages were functionally broken – reverted + unpublished

User reported a real failure using the published package: lacc -c ... test1.c failed with Unable to resolve include file 'gnu/stubs-64.h' – i.e. the 32-bit-*compiled* lacc binary was still trying to target x86_64 when compiling other code.

Root-caused in upstream’s own configure script: host (used to pick the codegen backend) is set from --build= when --host= isn’t given, and the case "$host" only branches on arm64-*/aarch64-* vs. everything else (default -> #define x86_64 1, backend=src/backend/x86_64). There is no 32-bit x86 backend in this project at all – only src/backend/x86_64 and src/backend/arm64 exist (src/lacc.c’s #ifdef x86_64 / #ifdef ARM64 amalgamation guards confirm it). So this PKGBUILD’s hardcoded ./configure --build=x86_64-linux was never the actual bug – even a correct per-arch --build=i686-linux etc. would still fall into the default case and select the x86_64 backend, because lacc genuinely has no other x86 target. The resulting 32-bit ELF binary internally still emits x86_64 codegen and unconditionally registers __LP64__/__x86_64__ macros (src/preprocessor/macro.c) for anything it compiles – hence gnu/stubs.h picking the (nonexistent, on a real 32-bit system) stubs-64.h.

Fix: reverted arch=() back to (x86_64) (matching the 2026-08-19 guidance), pkgrel left at 2, .SRCINFO regenerated. Also removed the already-published i486/i686/pentium4 lacc-git + lacc-git-debug packages from the live repo (repo-remove on each arch’s db, then deleted the .pkg.tar.zst/.sig files) – confirmed clean afterward (x86_64 untouched, other three archs empty of lacc-git*). User explicitly approved the removal (a “keep the broken packages live” option was also offered and declined).

Lesson: a passing check() is not proof a cross-compiled build is functionally correct – this package’s check() was a no-op, and even a real one would only exercise lacc’s own self-build, not what it does when used to compile arbitrary other code. Verifying “did it build as a native N-bit ELF” is not the same question as “does its codegen target N-bit” for a compiler.