为何同一extern块添加多link属性会导致Rust链接C库失败？

我需要将多个C静态库链接到Rust项目，最初在同一个extern块上添加了多个#[link]属性，代码如下：

use libc::{c_int};

#[link(name = "zlib", kind = "static")]
#[link(name = "libpng", kind = "static")]
#[link(name = "vec", kind = "static")] 
extern "C" {        
    pub fn entrypoint(argc: c_int, argv: *mut *mut u8) -> c_int;
    pub fn just_crash() -> c_int;
}

同时使用build.rs脚本添加C库（.a文件）的搜索路径：

fn main() {
    stop_if_unknown_os();
    let dir = env::var("CARGO_MANIFEST_DIR").unwrap();
    let cwd = Path::new(&dir);

    println!("cargo:rustc-link-search=native={}", cwd.display());
    println!("cargo:rustc-link-search=native={}/../install/lib", cwd.display());
}

执行cargo build -vv时，出现错误提示vec库中使用的libpng函数未找到；但将每个#[link]属性拆分到独立的extern块后，编译成功：

#[link(name = "vec", kind = "static")] 
extern "C" {        
    pub fn entrypoint(argc: c_int, argv: *mut *mut u8) -> c_int;
    pub fn just_crash() -> c_int;
}

#[link(name = "png16", kind = "static")]
extern "C" {}

#[link(name = "zlib", kind = "static")]
extern "C" {}

请问为何最初的方式无法正常工作？

这背后主要是链接器的静态库处理顺序和Rust对#[link]属性的解析逻辑共同导致的：

• 静态库的链接顺序规则
  链接器处理静态库时是从左到右依次扫描，只有当遇到未定义的符号时，才会从后续的库中查找对应的实现。如果一个库依赖另一个库的符号，那么被依赖的库必须放在依赖它的库的后面。
  比如这个场景中，vec依赖libpng，libpng又依赖zlib，正确的链接顺序应该是：vec → libpng → zlib。这样链接器处理vec时，遇到未定义的libpng符号，会在后续的libpng库中找到；处理libpng时，未定义的zlib符号也能在后续的zlib库中找到。

• 同一extern块下的#[link]顺序问题
  当在同一个extern块上添加多个#[link]属性时，Rust会严格按照编写顺序将库传递给链接器，也就是：zlib → libpng → vec。
  这个顺序完全颠倒：链接器先处理zlib，此时没有未定义符号需要它解决；接着处理libpng，它依赖的zlib符号已经被处理过（这一步没问题）；最后处理vec时，它需要的libpng符号已经不在链接器的扫描范围内（链接器不会回头重新扫描前面的库），因此会报符号未找到的错误。

• 拆分extern块后的顺序调整
  把每个#[link]拆分到独立的extern块时，Rust编译器会根据符号依赖关系自动调整链接顺序，确保被依赖的库排在后面。同时修正了libpng的链接名称为png16（对应实际的静态库文件libpng16.a，#[link]的name需要去掉lib前缀和.a后缀），解决了库文件匹配问题，最终链接顺序符合要求，编译成功。

内容的提问来源于stack exchange，提问作者Doublecouponday