build.rs找不到本地静态库的libvmaf，可能缺少一个-L标志？

Question

我试图在生锈中生成到libvmaf的绑定。我已经将vmaf作为一个git子模块导入，并且我的构建步骤似乎在工作，当我检查构建工件时，我可以看到文件正像我所期望的那样被生成。

下面是我遇到的具体错误：

cargo build
   Compiling libvmaf-rs v0.1.0 (/home/brandon/repos/libvmaf-rs)
error: could not find native static library `libvmaf`, perhaps an -L flag is missing?

error: could not compile `libvmaf-rs` due to previous error

下面是构建目录的树，深度为4；我关心的静态库位于./out/build/src/libvmaf.a

.
├── invoked.timestamp
├── out
│   ├── bindings.rs
│   └── build
│       ├── build.ninja
│       ├── compile_commands.json
│       ├── doc
│       ├── include
│       │   ├── libvmaf
│       │   └── vcs_version.h
│       ├── meson-info
│       │   ├── intro-benchmarks.json
│       │   ├── intro-buildoptions.json
│       │   ├── intro-buildsystem_files.json
│       │   ├── intro-dependencies.json
│       │   ├── intro-installed.json
│       │   ├── intro-install_plan.json
│       │   ├── intro-projectinfo.json
│       │   ├── intro-targets.json
│       │   ├── intro-tests.json
│       │   └── meson-info.json
│       ├── meson-logs
│       │   └── meson-log.txt
│       ├── meson-private
│       │   ├── build.dat
│       │   ├── cleantrees.dat
│       │   ├── cmd_line.txt
│       │   ├── coredata.dat
│       │   ├── install.dat
│       │   ├── libvmaf.pc
│       │   ├── meson_benchmark_setup.dat
│       │   ├── meson.lock
│       │   ├── meson_test_setup.dat
│       │   ├── sanitycheckc.c
│       │   ├── sanitycheckc.exe
│       │   ├── sanitycheckcpp.cc
│       │   └── sanitycheckcpp.exe
│       ├── meson-uninstalled
│       │   └── libvmaf-uninstalled.pc
│       ├── src
│       │   ├── config.asm
│       │   ├── config.h
│       │   ├── liblibvmaf_cpu.a
│       │   ├── liblibvmaf_cpu.a.p
│       │   ├── liblibvmaf_feature.a
│       │   ├── liblibvmaf_feature.a.p
│       │   ├── libvmaf.a # Trying to link to this!
│       │   ├── libvmaf.a.p
│       │   ├── libvmaf.so -> libvmaf.so.1
│       │   ├── libvmaf.so.1 -> libvmaf.so.1.1.3
│       │   ├── libvmaf.so.1.1.3
│       │   ├── libvmaf.so.1.1.3.p
│       │   ├── libx86_avx2.a
│       │   ├── libx86_avx2.a.p
│       │   ├── vmaf_4k_v0.6.1.json
│       │   ├── vmaf_4k_v0.6.1.json.c
│       │   ├── vmaf_b_v0.6.3.json
│       │   ├── vmaf_b_v0.6.3.json.c
│       │   ├── vmaf_v0.6.1.json
│       │   ├── vmaf_v0.6.1.json.c
│       │   ├── vmaf_v0.6.1neg.json
│       │   └── vmaf_v0.6.1neg.json.c
│       ├── test
│       │   ├── test_cambi
│       │   ├── test_cambi.p
│       │   ├── test_ciede
│       │   ├── test_ciede.p
│       │   ├── test_context
│       │   ├── test_context.p
│       │   ├── test_cpu
│       │   ├── test_cpu.p
│       │   ├── test_dict
│       │   ├── test_dict.p
│       │   ├── test_feature
│       │   ├── test_feature_collector
│       │   ├── test_feature_collector.p
│       │   ├── test_feature_extractor
│       │   ├── test_feature_extractor.p
│       │   ├── test_feature.p
│       │   ├── test_log
│       │   ├── test_log.p
│       │   ├── test_luminance_tools
│       │   ├── test_luminance_tools.p
│       │   ├── test_model
│       │   ├── test_model.p
│       │   ├── test_picture
│       │   ├── test_picture.p
│       │   ├── test_predict
│       │   ├── test_predict.p
│       │   ├── test_ref
│       │   ├── test_ref.p
│       │   ├── test_thread_pool
│       │   └── test_thread_pool.p
│       └── tools
│           ├── vmaf
│           ├── vmafossexec
│           ├── vmafossexec.p
│           └── vmaf.p
├── output
├── root-output
└── stderr

这是我的build.rs文件

extern crate meson;
use std::env;
use std::fs::canonicalize;
use std::path::PathBuf;

fn main() {
    //env::set_var("RUST_BACKTRACE", "1");
    let build_dir = PathBuf::from(env::var("OUT_DIR").unwrap()).join("build");
    let lib_dir = build_dir.join("src");

    let build_dir_str = build_dir.to_str().unwrap();
    let lib_dir_str = lib_dir.to_str().unwrap();

    meson::build("vmaf/libvmaf", build_dir_str);

    println!("cargo:rustc-link-lib=static=libvmaf");
    println!("cargo:rustc-link-search=native={lib_dir_str}"); // I believe this linker option is the problem

    // Path to vendor header files
    let headers_dir = PathBuf::from("vmaf/libvmaf/include");
    let headers_dir_canonical = canonicalize(headers_dir).unwrap();
    let include_path = headers_dir_canonical.to_str().unwrap();

    // Generate bindings to libvmaf using rust-bindgen
    let bindings = bindgen::Builder::default()
        .header("vmaf/libvmaf/include/libvmaf/libvmaf.h")
        .clang_arg(format!("-I{include_path}"))
        .parse_callbacks(Box::new(bindgen::CargoCallbacks))
        .generate()
        .expect("Unable to generate bindings");

    // Write bindings to build directory
    let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
    bindings
        .write_to_file(out_path.join("bindings.rs"))
        .expect("Couldn't write bindings!");
}

从我可以告诉我的cargo:rustc-link-search链接器选项是正确的，但是我需要一些关于为什么链接器找不到libvmaf的指导。

-编辑:我在构建脚本中添加了一个部分，该脚本将lib_dir_str输出到stderr，在将其转换为字符串之前，我还对lib_dir进行了规范化，以查看这是否有帮助。在build目录中，我可以看到一个带有stderr输出的文件。如果我ls到构建目录中希望找到(并链接到) libvmaf.a的部分的规范路径，我可以看到libvmaf.a。如果我正确地理解了cargo:rustc-link-search选项等同于编译器中的-L标志，那么为什么如果我检查目录，我就可以看到我想链接到的本机静态库，但不知怎么仍然找不到并链接到libvmaf。

-使用cargo build -v进行编辑--我可以看到build命令的详细输出。这样，我就可以确切地看到rustc是如何被调用的。

`rustc --crate-name libvmaf_rs --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=5225226d4097e5e3 -C extra-filename=-5225226d4097e5e3 --out-dir /home/brandon/repos/libvmaf-rs/target/debug/deps -C incremental=/home/brandon/repos/libvmaf-rs/target/debug/incremental -L dependency=/home/brandon/repos/libvmaf-rs/target/debug/deps -L native=/home/brandon/repos/libvmaf-rs/target/debug/build/libvmaf-rs-f8ca4c95356c61cf/out/build/src -l static=libvmaf`

如您所见，有两个-L参数传递给编译器，而-l参数被设置为libvmaf。

Answer 1

在类似unix的系统上，编译器和链接器会自动将lib后缀添加到通过-l提供的库名中。因此，您需要您的build.rs发出：

cargo:rustc-link-lib=static=vmaf

有一个链接修饰符verbatim，您可以使用它来抑制这种行为，但它是目前不稳定。无论如何，我不建议在类似unix的系统上使用lib作为所有库的前缀，而在Windows上则不是这样，所以让编译器根据平台自动添加前缀是件好事。