From 8383746a72eb7e74d457b0099cf4e6d08cc03049 Mon Sep 17 00:00:00 2001 From: vikingowl Date: Wed, 13 May 2026 13:19:46 +0200 Subject: [PATCH] fix(cargo): pin ld.bfd to dodge LLD's arg-order strict mode (chroot fix) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- .cargo/config.toml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 .cargo/config.toml diff --git a/.cargo/config.toml b/.cargo/config.toml new file mode 100644 index 0000000..aa6be2c --- /dev/null +++ b/.cargo/config.toml @@ -0,0 +1,21 @@ +# Pin the linker to GNU ld.bfd for x86_64 builds. +# +# Background: Arch's `extra/rust` package patches rustc to default to +# `-fuse-ld=lld`. mlua-sys + lua-src emit `cargo:rustc-link-lib=static:-bundle=lua5.4` +# (negative-bundle = "static, don't pack into the rlib") plus a separate +# `cargo:rustc-link-search=native=$OUT_DIR/lib`. rustc serialises these into +# the final linker invocation with `-llua5.4` appearing BEFORE `-L .../out/lib`. +# Single-pass linkers like LLD process args in order and can't satisfy +# `-llua5.4` because the search path it's in hasn't been added yet — the +# entire chroot build fails with 60+ undefined-symbol errors out of mlua. +# +# `ld.bfd` does multi-pass resolution and finds the archive regardless of +# argument order, matching the behaviour of rustup's default-linker rustc +# binaries used outside Arch packaging. binutils (which provides bfd) is +# already a build-essential dep of the chroot, so this adds no install cost. +# +# Local cargo (rustup toolchain) doesn't suffer from the ordering bug, but +# pinning bfd here keeps both environments byte-identical. + +[target.x86_64-unknown-linux-gnu] +rustflags = ["-C", "link-arg=-fuse-ld=bfd"]