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

Add a way to define relative paths in rustc-link-search #6725

Open
oblique opened this issue Mar 7, 2019 · 3 comments
Open

Add a way to define relative paths in rustc-link-search #6725

oblique opened this issue Mar 7, 2019 · 3 comments
Labels
A-linkage Area: linker issues, dylib, cdylib, shared libraries, so C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@oblique
Copy link

oblique commented Mar 7, 2019

Describe the problem you are trying to solve

I'm writing a project that uses zmq and zmq-sys which need to be cross-compiled for arm-unknown-linux-gnueabi.

zmq-sys doesn't compile libzmq on its own but we can specify the lib and include directories by using LIBZMQ_LIB_DIR and LIBZMQ_INCLUDE_DIR. However zmq's build.rs requires zmq-sys, which means I also need a compiled binary for x86_64-unknown-linux-gnu target too. So I can not just use the environment variables of zmq-sys since LIBZMQ_LIB_DIR will point to a wrong directory.

I did the following workaround:

[target.arm-unknown-linux-gnueabi]
linker = "arm-none-linux-gnueabi-gcc"

[target.arm-unknown-linux-gnueabi.zmq]
rustc-link-search = ["native=/home/user/zmq-example/vendor/libzmq/lib/arm"]
rustc-link-lib = ["static=zmq", "dylib=stdc++"]

[target.x86_64-unknown-linux-gnu.zmq]
rustc-link-search = ["native=/home/user/zmq-example/vendor/libzmq/lib/x86_64"]
rustc-link-lib = ["static=zmq", "dylib=stdc++"]

The problem with the above workaround is that all developers need to have the same absolute path to the compiled binaries.

Describe the solution you'd like

I would like to have a way to define a relative path in rustc-link-search.

Another solution could be a way to define a environment variables per target.

@oblique oblique added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Mar 7, 2019
@ehuss
Copy link
Contributor

ehuss commented Mar 7, 2019

I'm a little confused about the request for relative paths. The paths should support being relative to the package root. Is that not working for you?

@oblique
Copy link
Author

oblique commented Mar 7, 2019

You are correct, so let me rephrase: Is there a way to provide paths that are relative to my project's root (/home/user/zmq-example) instead of zmq-sys package's root (/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.9.0).

I don't want to have absolute paths of my project's root in .cargo/config since it restricts other developers.

@nikonthethird
Copy link

nikonthethird commented Apr 19, 2019

So I have a workaround for this problem. I am cross-compiling DBus and have the same problem as you: I have to point the rustc-link-search to some place inside my repository, relative to the root of the repository, not relative to where Cargo extracted the package.

In short, you have to use a build.rs build script to set rustc-link-search.

This is my Cargo config file:

[build]
target = "armv7-unknown-linux-gnueabihf"

[target.armv7-unknown-linux-gnueabihf.dbus]
rustc-link-search = [
    # Provided by the build script.
]

rustc-link-lib = [
    "dbus-1",
    "gcrypt",
    "gpg-error",
    "lz4",
    "lzma",
    "pcre",
    "selinux",
    "systemd",
]

And this is my build.rs build script:

use std::env::var;

fn main() {
    let manifest_dir = var("CARGO_MANIFEST_DIR").unwrap();
    println!("cargo:rustc-link-search={}/libraries/lib/arm-linux-gnueabihf", manifest_dir);
    println!("cargo:rustc-link-search={}/libraries/usr/lib/arm-linux-gnueabihf", manifest_dir);
}

The CARGO_MANIFEST_DIR environment variable points to the crate with the build script, and I placed the external libraries into a libraries folder there. After doing this the build works again, no more hard-coded absolute paths.

Furthermore in your case you would also have to read the TARGET environment variable and set the paths according to it.

@epage epage added A-links Area: `links` native library links setting A-linkage Area: linker issues, dylib, cdylib, shared libraries, so S-triage Status: This issue is waiting on initial triage. and removed A-links Area: `links` native library links setting labels Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linker issues, dylib, cdylib, shared libraries, so C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

4 participants