Mixing static and dynamic libraries in Rust FFI

Question

My executable Rust crate uses a native library libfoo.a which depends on a shared library libbar.so, but does not expose it at all.

My Rust FFI uses the methods from libfoo, so I defined a link attribute on my extern code::

#[link(name="foo", kind="static")]
extern "C"{
    pub fn do_foo();
}

and my build.rs included from Cargo.toml using build="build.rs"

fn main() {
    let libs = &[(Some("../libs/foo/1.0/"), "static=foo"), // use ../libs/foo/1.0/libfoo.a
                 (None, "bar")]; // use libbar.so using LD_LIBRARY_PATH
    for &(ref m_path, ref lib) in libs {
        if let &Some(static_path) = m_path {
            println!("cargo:rustc-link-search={}", &static_path);
        }
        println!("cargo:rustc-link-lib={}", &lib);
    }
}

which outputs

cargo:rustc-link-search=../libs/foo/1.0/
cargo:rustc-link-lib=static=foo
cargo:rustc-link-lib=bar

Theoretically, I expect Rust to link against libfoo.a and libbar.so. The problem is that rustc does not even try to acknowledge libbar.

cargo build --debug ends with

/home/author/src/foo/foo.c:21: undefined reference to 'bar_do_stuff'
collect2: error: ld returned 1 exit status

When I inspect the linker command, there is an -L ../libs/foo/1.0 argument, as well as -l foo, but there is no trace of -l bar !

If I manually add the -l bar to cc, it builds (and runs) just fine.

Could you let me know what I am missing? Should I create an FFI binding for libbar even though I don't use it in Rust and it is not exposed from libfoo's API?

Answer 1

The issue is a conflict between the #[link] attribute in the FFI definition and the output of the build.rs build script.

It would seem that the #[link] attribute is instructing rustc to ignore the cargo:rustc-link-* instructions.

The fix was as simple as removing the #[link] attribute.