llvm-mos-git
Build times (auto-updated)
- x86_64: 1h49m (2026-10-06 12:36 UTC, MAKEFLAGS=-j6)
- Path: arch/maintained/llvm-mos-git
- Same trivial missing-
git-in-makedepends bug as memory/adtpro-git.md and
siblings. Fixed 2026-07-07: added git, bumped pkgrel 1 -> 2, regenerated
.SRCINFO. Queued for rebuild. Note: this is a large LLVM build, expect a
long compile time.
- 2026-08-02: attempted the rebuild – confirmed it’s a genuinely long build (got
to 3618/5219 ninja targets on the main LLVM/clang build before failing), not
disk/resource starved (22GB free throughout, no exhaustion). Failed in a
nested sub-build:
runtimes/builtins-mos-unknown-unknown-build
(cross-compiling compiler-rt builtins for the custom 6502 “mos” target) –
ninja: build stopped: subcommand failed. The actual underlying compiler
error got lost because this run’s output was captured with tail -20 per
package in a batch, which truncated past the real error line. Re-run in
isolation (not batched) and capture full output to actually diagnose – not
fixed, root cause unknown.
- 2026-10-05: root cause found (full log this time, from a
-git batch pass;
failed at ninja target 3766/5396, ~3.5h in). Same
builtins-mos-unknown-unknown sub-build, now with the real error visible:
clang: error: unsupported option '-march=' for target 'mos-unknown-unknown'.
The sub-build’s clang invocation carries
-march=x86-64 -mtune=generic ... -flto ... – Arch’s host makepkg.conf
CFLAGS/CXXFLAGS/LDFLAGS leaking via the environment into CMake’s
cross-compilation sub-build for the freestanding 6502 mos-unknown-unknown
target, which rejects x86_64-specific flags outright. options=('!lto') in
this PKGBUILD did nothing against this – that only toggles makepkg’s own
conditional flag-appending, not flags already baked into the chroot’s
makepkg.conf CFLAGS string itself, so -flto rode along too.
- Fix applied, NOT yet retried: added
unset CFLAGS CXXFLAGS CPPFLAGS LDFLAGS at the top of build(), before the
cmake invocation, so none of the host flags reach any of MOS.cmake’s
per-target sub-builds (it sets its own flags per target internally). pkgrel
2 -> 3, regenerated .SRCINFO. Deliberately not requeued for a retry in
the same session – this is a ~3.5h+ build to get back to the failure point
alone, so confirming the fix actually works costs real time; left for the user
to decide whether to spend that now or batch it with other long builds later.
If retried: watch for whether unsetting LDFLAGS breaks anything in the final
fluxengine-style link step for the host-side clang/ llvm-mc tools
themselves (unlikely – Release build type supplies its own optimization flags
– but not yet confirmed empirically).