ack-git
Build times (auto-updated)
- x86_64: 15m31s (2026-10-05 18:02 UTC, MAKEFLAGS=-j6)
- Path: arch/maintained/ack-git
- User (Andreas Baumann) is the current AUR maintainer (the PKGBUILD’s own
# Maintainer: comment is stale, still crediting the original submitter –
AUR’s own maintainer field is the authoritative source, not the PKGBUILD
comment).
- “The Amsterdam Compiler Kit” – a retargetable multi-platform C compiler suite
(linux386, linuxppc, linuxmips, etc. as cross targets) from
github.com/davidgiven/ack (a modernized fork; the PKGBUILD’s url= still
points at the older tack.sourceforge.net).
2026-08-19: fixed the compiled-in ACKDIR path (package() bug)
- User reported having to manually
export ACKDIR=/usr to use the installed
compiler – otherwise it doesn’t find its runtime support files. Root cause
traced through the actual ACK source:
- The
ack driver falls back to a compiled-in default path (em_dir,
initialized from the EM_DIR macro) whenever the ACKDIR env var isn’t set
(util/ack/main.c, util/ack/rmach.c).
EM_DIR gets baked in at build time from the Makefile’s PREFIX variable
(h/build.py: echo '#define EM_DIR "$(PREFIX)"' ...).
- The top-level
Makefile’s install target
(install: all; tar -C $(INSDIR) . | tar -C $(PREFIX)) depends on all,
and its build system (ab.py/ninja) re-triggers all whenever any build
variable (including PREFIX) changes since the last invocation.
- The tracked PKGBUILD ran
build() with PREFIX=/usr (correct – bakes
EM_DIR="/usr"), then package() with a different
PREFIX="${pkgdir}/usr" for make ... install. That PREFIX change
invalidated the build system’s cache and recompiled the ack driver
with EM_DIR baked in as the ephemeral pkgdir path instead of /usr –
exactly matching the user’s symptom.
FINAL_PREFIX (which an earlier, uncommitted local edit had added to both
make invocations, guessing it was the fix) is not referenced anywhere
in ACK’s build system at all (verified via exhaustive grep of the whole
source tree) – a red herring, though harmless (an unused variable).
- Real fix:
package() no longer calls make ... install at all.
install’s actual action is just a tar copy of $(OBJ)/staging (a
PREFIX-independent build-tree path, always .obj/staging, containing
bin/, lib/, share/ directly) into $(PREFIX). Replaced with a direct
cp -a .obj/staging/. "$pkgdir"/usr/ – copies the correctly-built (already
has EM_DIR=/usr baked in from build()) tree without ever re-invoking make
with a different PREFIX, so nothing gets recompiled with the wrong path.
pkgrel 1 (auto-reset by -git pkgver recompute) -> 2 (maintained/,
plain integer) for this fix.
2026-08-19 (same day): i686/pentium4 test-suite bug, fixed by targeting “compiler” instead of “all”
- Also added
pentium4 (upstream only had i686 x86_64) to try extending
32-bit coverage per this session’s mandate. Both i686 and pentium4 initially
failed identically, deep in ACK’s own cross-target test suite: a linuxppc
test binary (compiled for a completely unrelated target platform, as part of
PLATS=all building/testing every supported cross-target) fails self-tests
(@@FAIL 0x52 etc.) when executed through ACK’s own PowerPC emulator
(util/emu, a native HOSTCC-built tool). x86_64 doesn’t hit this. Points to
the emulator’s own correctness depending on the host’s word size (works when
the emulator itself is compiled as x86_64, breaks when compiled natively for
i686/pentium4) – a bug in ACK’s own vendored/upstream test infrastructure,
unrelated to our packaging and unrelated to the target platform we actually
care about.
- Real fix found (traced through
build.py’s target composition):
all = compiler + examples + tests-for-select-platforms (the TEST_PLATS
list includes linuxppc), while compiler alone builds every platform’s
actual toolchain/libraries – the same output install/package() needs –
with no test execution at all. build() now targets +compiler (not the
make default, all) specifically on i686/pentium4 via a case ${CARCH}
branch, while x86_64 still builds/runs the full all target (including tests)
since it doesn’t hit the bug. All three arches build and publish cleanly at
pkgrel=3.
- Lesson: before reverting an arch for a test-suite-only failure, check whether
the build system distinguishes “build” from “build + self-test” as separate
targets –
ab.py/ninja-based builds often do, and skipping just the tests
can be far less invasive than dropping the whole arch.