问题描述 #

我在Arch Linux上搭建了Rust交叉编译环境，从x86_64主机编译x86_64-unknown-linux-musl和aarch64-unknown-linux-musl目标。默认情况下，两个目标的二进制都是完全静态链接的，但当我通过RUSTFLAGS=-Clink-args=-fuse-ld=lld强制使用LLD链接器时，aarch64目标的二进制会动态链接解释器/lib/ld-musl-aarch64.so.1，而x86_64目标不受影响。

复现步骤 #

1. 安装依赖与配置工具链

sudo pacman -Syu rustup musl musl-aarch64
rustup toolchain install stable
rustup target add {x86_64,aarch64}-unknown-linux-musl

2. 创建项目并配置交叉编译

cargo new build-test
cd build-test
mkdir .cargo
cat >.cargo/config.toml <<<'
[target.aarch64-unknown-linux-musl]
linker = "aarch64-linux-musl-gcc"'

3. 无LLD强制的编译（正常情况）

cargo build --target={x86_64,aarch64}-unknown-linux-musl
# 验证两个二进制都不链接解释器
file target/*/debug/build-test

现象：两个目标的二进制都是完全静态的，无解释器：

target/aarch64-unknown-linux-musl/debug/build-test: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, with debug_info, not stripped
target/x86_64-unknown-linux-musl/debug/build-test: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=c3b20ad630c987c5b704af0564065d6a111c3a07, with debug_info, not stripped

4. 强制使用LLD的编译（异常情况）

cargo clean
RUSTFLAGS=-Clink-args=-fuse-ld=lld cargo build --target={x86_64,aarch64}-unknown-linux-musl
# 验证aarch64二进制链接了解释器
file target/*/debug/build-test

现象：x86_64目标仍为完全静态，但aarch64目标出现了解释器：

target/aarch64-unknown-linux-musl/debug/build-test: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, interpreter /lib/ld-musl-aarch64.so.1, with debug_info, not stripped
target/x86_64-unknown-linux-musl/debug/build-test: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=66daf14742c611a2e29015c603674cb87c92258e, with debug_info, not stripped

环境版本

$ pacman -Q musl musl-aarch64
musl 1.2.5-6
musl-aarch64 1.2.5-6

$ cargo --version
cargo 1.91.1 (ea2d97820 2025-10-10)
$ rustc --version
rustc 1.91.1 (ed61e7d7e 2025-11-07)

回答 #

问题原因 #

这个差异源于musl交叉编译工具链与LLD交互时的参数传递行为差异：

1. 默认链接器的隐式静态行为
   你配置的aarch64-linux-musl-gcc是musl提供的GCC包装器，它默认会自动添加-static参数，强制链接musl的静态标准库，并且生成完全不依赖动态解释器的二进制。x86_64-linux-musl-gcc的行为也是如此。

2. 强制LLD时的静态参数丢失
   当你通过-Clink-args=-fuse-ld=lld指定使用LLD时，该参数会被传递给aarch64-linux-musl-gcc，让它调用LLD替代默认的GNU ld。但此时，aarch64-linux-musl-gcc在调用LLD时没有正确传递原本默认的-static参数，导致LLD生成了带有musl解释器的"半静态"二进制——虽然库是静态链接的，但仍保留了解释器路径。

   而x86_64目标无此问题，是因为x86_64版本的musl-gcc在配合LLD时，仍能正确传递全静态所需的参数，或者LLD对x86_64 MUSL目标的全静态处理更完善。

解决方法 #

有两种可靠的方式实现LLD下的全静态AArch64 MUSL二进制：

方法1：显式添加-static链接参数

在强制使用LLD时，显式传递-static参数给链接器，确保LLD生成完全静态的二进制：

RUSTFLAGS="-Clink-args=-fuse-ld=lld -Clink-args=-static" cargo build --target=aarch64-unknown-linux-musl

也可以将配置写入项目级.cargo/config.toml，避免重复输入：

[target.aarch64-unknown-linux-musl]
linker = "aarch64-linux-musl-gcc"
rustflags = ["-Clink-args=-fuse-ld=lld", "-Clink-args=-static"]

方法2：直接使用musl版LLD作为链接器

跳过GCC包装器，直接指定AArch64版本的musl LLD作为链接器，让Rust直接调用LLD并传递全静态参数：
修改项目的.cargo/config.toml：

[target.aarch64-unknown-linux-musl]
linker = "aarch64-linux-musl-ld.lld"
rustflags = ["-Clink-args=-fuse-ld=lld"]

然后正常编译即可：

cargo build --target=aarch64-unknown-linux-musl

验证效果 #

编译完成后，用file命令验证：

file target/aarch64-unknown-linux-musl/debug/build-test

预期输出（无解释器）：

target/aarch64-unknown-linux-musl/debug/build-test: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, with debug_info, not stripped

额外说明 #

• 如果你想全局启用LLD，可以将rustflags配置添加到用户级~/.cargo/config.toml中。
• 该问题是特定于AArch64 MUSL与LLD的交互，x86_64 MUSL无需额外配置即可正常工作。