Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo nightly fails to create working executable when linking shared library #3838

Closed
nbigaouette opened this issue Mar 17, 2017 · 5 comments

Comments

@nbigaouette
Copy link

I want to use an FFI crate exposing a C library's API in Rust. This crate is tensorflow-sys, hosted here.

I am facing an issue when trying to run the crate's tests using a nightly cargo (1.17.0-nightly (b1e31766d 2017-03-03)) while the tests passes fine using stable (1.16).

The issue is that the nightly compiled test binary cannot find, when run, the .so library. See issue tensorflow/rust#71.

I have created a simple repository to illustrate the problem: https://github.com/nbigaouette/tfsys

The repository contains the same build.rs file as used in the original crate, stripped of everything "not needed" (it simply download the .so library and instruct cargo to link it).

I believe the problem is in cargo and not in the original crate (its build script) because cargo nightly version regressed compared to the stable version.

@alexcrichton
Copy link
Member

I think this may be related to #3651 perhaps? That change specifically stopped automatically adding directories to LD_LIBRARY_PATH that were outside the OUT_DIR folders. Is the .so library you're building falling into that category? If so, would it be possible to move it into OUT_DIR?

@nbigaouette-eai
Copy link

Thanks Alex! It looks like this was the problem.

I've replaced the line:

println!("cargo:rustc-link-search={}", lib_dir.display());

with one that copies the libtensorflow.so library to OUT_DIR plus a modified link search:

println!("cargo:rustc-link-search={}", env::var("OUT_DIR").unwrap());

The test seems to run (the test binaries can find the .so file). Is it expected to have to add OUT_DIR to cargo:rustc-link-search?

What is the best practice to build a -sys crate that depends on a library that is not available on the system (either prebuilt or compiled)? Should it be copied to OUT_DIR as it is the case here? Do you have an example crate the does it correctly that I could check out?

Thanks a lot! 👍

@alexcrichton
Copy link
Member

Ok, good to know the cause at least!

For now the predominant convention among *-sys crates is that they either arrange for the library to be in OUT_DIR (via compiling, downloading, copying, etc) or link to a system version. Unfortunately I don't know of any examples of downloading prebuilt binaries :(

@nbigaouette-eai
Copy link

nbigaouette-eai commented Mar 17, 2017

Great, thanks a lot! I'll close this and fix the build.rs script.

EDIT: I actually can't close this... Please do so.

@alexcrichton
Copy link
Member

Sure thing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants