ack-git

• 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.