Cargo: rustc-link-searchで相対パスを定義する方法を追加します

作成日 2019年03月07日  ·  3コメント  ·  ソース: rust-lang/cargo

解決しようとしている問題を説明してください

zmqzmq-sysを使用するプロジェクトを作成していますが、これらはarm-unknown-linux-gnueabi用にクロスコンパイルする必要があります。

zmq-sysはそれ自体ではlibzmqをコンパイルしませんが、 LIBZMQ_LIB_DIRLIBZMQ_INCLUDE_DIRを使用して、libを指定し、ディレクトリを含めることができます。 ただしzmqのbuild.rsにはzmq-sysが必要です。つまり、 x86_64-unknown-linux-gnuターゲットにもコンパイル済みのバイナリが必要です。 したがって、 LIBZMQ_LIB_DIRが間違ったディレクトリを指しているため、 zmq-sysの環境変数を使用することはできません。

次の回避策を実行しました。

[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++"]

上記の回避策の問題は、すべての開発者がコンパイルされたバイナリへの同じ絶対パスを持っている必要があることです。

希望するソリューションを説明してください

rustc-link-searchで相対パスを定義する方法が欲しいのですが。

別の解決策は、ターゲットごとに環境変数を定義する方法である可能性があります。

C-feature-request

最も参考になるコメント

したがって、この問題の回避策があります。 私はDBusをクロスコンパイルしていて、あなたと同じ問題を抱えています。Cargoがパッケージを抽出した場所ではなく、リポジトリのルートを基準にして、リポジトリ内のどこかにrustc-link-searchを指定する必要があります。

つまり、 build.rsビルドスクリプトを使用してrustc-link-searchを設定する必要があります。

これは私の貨物configファイルです:

[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",
]

そして、これは私のbuild.rsビルドスクリプトです。

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);
}

CARGO_MANIFEST_DIR環境変数は、ビルドスクリプトを含むクレートを指し、外部ライブラリをそこのlibrariesフォルダーに配置しました。 これを行った後、ビルドは再び機能し、ハードコーディングされた絶対パスはなくなります。

さらに、あなたの場合、 TARGET環境変数を読み取り、それに応じてパスを設定する必要があります。

全てのコメント3件

相対パスのリクエストについて少し混乱しています。 パスは、パッケージルートからの相対パスをサポートする必要があります。 それはあなたのために働いていませんか?

正解です。言い換えると、 zmq-sysパッケージのルート( /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.9.0 $)ではなく、プロジェクトのルート( /home/user/zmq-example )に相対的なパスを提供する方法はありますか。

他の開発者を制限するため、プロジェクトのルートの絶対パスを.cargo/configに含めたくありません。

したがって、この問題の回避策があります。 私はDBusをクロスコンパイルしていて、あなたと同じ問題を抱えています。Cargoがパッケージを抽出した場所ではなく、リポジトリのルートを基準にして、リポジトリ内のどこかにrustc-link-searchを指定する必要があります。

つまり、 build.rsビルドスクリプトを使用してrustc-link-searchを設定する必要があります。

これは私の貨物configファイルです:

[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",
]

そして、これは私のbuild.rsビルドスクリプトです。

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);
}

CARGO_MANIFEST_DIR環境変数は、ビルドスクリプトを含むクレートを指し、外部ライブラリをそこのlibrariesフォルダーに配置しました。 これを行った後、ビルドは再び機能し、ハードコーディングされた絶対パスはなくなります。

さらに、あなたの場合、 TARGET環境変数を読み取り、それに応じてパスを設定する必要があります。

このページは役に立ちましたか?
0 / 5 - 0 評価