Linking native libraries from `lib` crates: "perhaps an -L flag is missing?", but works for executables

help
1

Im trying statically link a native library, and i'm noticing that it works correctly iff I am building an executable:

I have the following files

  • src/main.rs
  • build.rs
  • Cargo.toml

My build.rs looks something like this:

fn main() {
         // assume the libraries are correctly installed
         println!("cargo:rustc-link-lib=static=<my_lib1>");
         println!("cargo:rustc-link-lib=static=<my_lib2>");
}

This works fine, and there wasnt any other configuration needed, and I can even call symbols from my_lib1 from within the binary!

However switching main.rs -> lib.rs produces the following error:

"[error]: could not find native static library <my_lib2>, perhaps an -L flag is missing?"

My goal in doing this was to create a "-sys" crate for my library, but I must be missing something.

Thank you in advance!

2

do you have both main.rs and lib.rs in the same package? if so, the -l option is only passed to rustc for the lib target, NOT for the bin target, which indicates your main.rs can build successfully due to the fact that it is actually not using any symbols from the library, NOT because it resolves the library path correctly.

3

No so the crate just has a lib.rs.

My goal is to have a sys crate that links all these libs and provides some basic bindings to them. Then I want to import this into another crate/binary and use it there. Preferably an importer of this sys crate shouldn't need a build script.

Which indicates your main.rs can build successfully due to the fact that it is actually not using any symbols from the library,

I dont think this is case, my main.rs declares an extern "C" block and calls it.

4

ok.

another guess is, you are using relative paths, and the native library file happens to be found by the main.rs crate, but not by the lib.rs crate.

you'd better provide more details about your setup, most of the time, there's nothing wrong in principle, but the devils are in details.

if you are linking to a library installed on the system, your build script is responsible to make sure the library is actually installed and find the path to it, and pass the correct command line flags to the linker. besides the cargo:rustc-link-lib directive, you might also need cargo:rust-link-search, which corresponds to the very -L option mentioned in the error message. this is especially important if the library is not installed in the default location such as /usr/lib64, /usr/local/lib etc.

if you are building the library from source, you definitely need to use cargo:rustc-link-search since the library will be put into $OUT_DIR of your crate. however, often times you may be using cc or cmake to manage the build process, in which case the linker flags should already be handled by these crates so you don't need to worry about it.

5

you'd better provide more details about your setup, most of the time, there's nothing wrong in principle, but the devils are in details.

Absolutely, appreciate you taking the time to think about this!

Ill provide more details later today but heres the last bit: I am indeed linking native libraries that are installed in the /usr directory. I find it strange that the same code works iff I have a main.rs. I have confirmed that everything is working correctly because I have actually used the FFI code in the main.rs and seen expected results.

I did find this thread that seems to describe a similar problem, and I imagine Cargo must have some rules about native libs that I dont know about.

Ill working on getting a reproduction with my actual libs later today.