cmake2

Build times (auto-updated)

• x86_64: 21m16s (2026-09-10 17:59 UTC, serial)

---

• Path: arch/private/cmake2
• Old CMake 2.8.12.2 (2013-era), pkgname=cmake2 (_pkgname=cmake). Added 2026-08-27 from the user’s own local cmake2_todo.tgz (a full prior AUR git checkout, upstream at https://github.com/ftalbrecht/aur, cmake2 branch — .git/ dropped, same as every other package pulled in this way this session).
• Coexists with the real cmake cleanly by construction — no conflicts=()/provides=() needed, this is why the user wanted it: installs entirely under /opt/cmake2, then symlinks cmake/ccmake/cpack/ctest into /usr/bin as cmake-2, ccmake-2, cpack-2, ctest-2 (suffixed, distinct from the real ones). Verified by inspecting the bundled prebuilt package’s file list, not just trusting the PKGBUILD’s package() logic.
• Source rehosted to src/ (cmake-2.8.12.2.tar.gz, still reachable at cmake.org/files/v2.8/... as of 2026-08-27, mirrored proactively anyway per this session’s established pattern). Verified md5 match against the existing PKGBUILD entry, along with both local patch files, before uploading.
• Real toolchain journey, all in one 2026-08-27 session:
  1. makedepends=('emacs' 'gcc10') — gcc10 didn’t exist anywhere (not in [core]/[extra], not on this host, not on archlinuxaba). First republished the bundled prebuilt cmake2-2.8.12.2-1-x86_64.pkg.tar.zst directly (repo_sign.sh + repo_publish.sh, skipping repo_build.sh) after verifying it trustworthy (its own -package.log showed a clean prior build, file list matched package()’s logic: /opt/cmake2/bin/* + /usr/bin/*-2 symlinks — the mechanism that lets it coexist with the real cmake cleanly, no conflicts=() needed, see above).
  2. Tried substituting gcc9 (published as a stopgap, see [[gcc9]]) — hit cc1: error: '-Wformat-security' ignored without '-Wformat' [-Werror=format-security] in Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test.c.o. Root cause found: Utilities/KWIML/test/CMakeLists.txt deliberately appends -Wno-format to CMAKE_<lang>_FLAGS for that one target (it intentionally tests malformed format strings) — this cancels any -Wformat added via environment CFLAGS regardless of ordering, so that fix attempt was doomed from the start. Same failure recurred identically with real gcc10 later, confirming it was never toolchain-version-specific.
  3. Once [[gcc10]] got published for real (fixing its own separate libsanitizer/kernel-header build issues — see that file), retried with the genuine gcc10 toolchain the PKGBUILD always wanted. Real fix for the KWIML issue: downgrade -Werror=format-security back to a plain warning instead of fighting -Wformat/-Wno-format — export CFLAGS="$CFLAGS -Wno-error=format-security" (+ CXXFLAGS) in build(), added before ./bootstrap. This isn’t touched by the later -Wno-format append, so it survives regardless of ordering.
  4. Build then progressed to a third, unrelated failure: a link error — /usr/bin/ld: /usr/lib/libicuuc.so.78: undefined reference to std::condition_variable::wait(...)@GLIBCXX_3.4.30. Root cause: gcc-10 prepends its own private, older libstdc++.so (/usr/lib/gcc/x86_64-pc-linux-gnu/10.5.0/) to the link search path ahead of the system’s newer one at /usr/lib — confirmed the system copy does have GLIBCXX_3.4.30 (strings .../libstdc++.so.6 | grep GLIBCXX_3.4.30), so the fix was just search-order, not a real ABI gap. Fixed with export LDFLAGS="-L/usr/lib $LDFLAGS" in build(), forcing the system libstdc++ to resolve first.
  5. Build fully succeeded after that (compile + link). package() then failed on a fourth, unrelated issue: emacs: error while loading shared libraries: libtree-sitter.so.0.26: cannot open shared object file during the cmake-mode.el byte-compile step — Arch’s own emacs package under-declares its tree-sitter runtime dependency (not auto-pulled into the chroot). Fixed by adding tree-sitter explicitly to makedepends.
  6. Built and published successfully at pkgrel 1 (unchanged — first real publish of this package, no prior version to bump past, [[feedback_pkgrel_vs_pkgver]]), producing both cmake2 and cmake2-debug.
  • i686 never attempted — no local i686 source tarball to build against locally, gcc10 only ever published for x86_64 (arch=('i686' 'x86_64') left as-is regardless, same reasoning as [[jdk6]]’s untouched i686 entry).
  • General lesson: four genuinely independent build/link/package failures in sequence, each masking the next until fixed one at a time — don’t assume a second failure after a fix is a sign the fix didn’t work; check whether it’s actually a new error at a later build stage first (build() → link → package() progressed steadily deeper each retry here).

2026-09-10: asked to update for “all archs” – stayed x86_64-only

arch=('i686' 'x86_64') was the original declared set, but i686 was never buildable (needs gcc10 for i686, which doesn’t exist – gcc10’s own PKGBUILD is arch=('x86_64') only, no i686 support at all). User agreed to skip i686 and try x86_64+aarch64 instead (64-bit only) – see [[gcc10]]’s own 2026-09-10 entry for the aarch64 attempt, which got gcc10 itself most of the way there (PGP key gap fixed, build reached deep into stage1 bootstrap) before hitting a hard OOM kill on eurobuild14 (1.8GB RAM, no swap). User’s call: not worth chasing further, gcc10 reverted to x86_64-only.

Result: arch=() trimmed to ('x86_64') alone (dropping the stale/unbuildable i686 entry entirely, not just leaving it unbuilt), pkgrel 1 -> 1.1 (real content change, private/ X.Y scheme — this package carries real local build fixes on top of an ancient pinned upstream release, same shape as adapted/). Rebuilt and republished x86_64 under the new pkgrel to keep the tracked PKGBUILD and the published repo in sync (no build-content change itself, purely the arch=()/pkgrel edit).