THIRD attempt at the chroot build. The real root cause: rustc's link
arg ordering plus Arch's `extra/rust` defaulting to `-fuse-ld=lld`.
lua-src emits `cargo:rustc-link-lib=static:-bundle=lua5.4` (negative
`-bundle` = "static, don't pack into the rlib") with a separate
`cargo:rustc-link-search=native=$OUT_DIR/lib`. rustc serialises these
into the final linker command line with `-llua5.4` appearing BEFORE
`-L .../mlua-sys-*/out/lib`. Single-pass linkers (LLD) honour args
left-to-right and fail to locate the archive at the time `-l` is
processed → 60+ undefined symbols out of mlua.
GNU `ld.bfd` does multi-pass resolution and finds the archive
regardless of arg order. rustup's stable toolchain (used locally)
defaults to bfd, which is why the bug never reproduced outside the
chroot despite identical Cargo.toml / Cargo.lock / cargo / rustc
versions.
Add `.cargo/config.toml` at the workspace root pinning bfd for
x86_64-unknown-linux-gnu via `rustflags = ["-C", "link-arg=-fuse-ld=bfd"]`.
binutils (which ships bfd) is already a build-essential dep of the
chroot — no new install cost. Local builds gain identical behaviour
to chroot, which is a nice side effect.
Verified locally: clean + frozen + features full → 84s, no link errors.
Sequence to reproduce the fix:
cargo clean
cargo build --frozen --release --features full
Reverts the previous two attempts to fix this:
- a4d4f30 (hoist mlua features to feature row)
- b3764b3 (drop optional from mlua/glob/notify)
... were both red herrings. mlua-sys's vendored feature WAS active in
the chroot — `Compiling lua-src v550.0.0` and `Compiling mlua-sys v0.10.0`
appear in build-logs/aur-test-20260513-131232.log and the link line
contains `-L .../mlua-sys-*/out/lib`. The static archive existed; LLD
just couldn't find it through the misordered arg list.
Re-run `just aur-local-test owlry` to confirm.
vikingowl
8383746a72