通常の動作の一部として、不安定なレガシー コードを含む別の実行可能ファイル fork()/execs() を使用する C++ 共有ライブラリがあります。この実行可能ファイルは、このライブラリ以外では役に立たないので、PATH ディレクトリに配置することは避けたいと思います。また、さまざまな場所に複数のコピーをインストールできるようにしたいので、ハードコードされたパスは望ましくありません。exec() がこの実行可能ファイルを見つけられるようにする RPATH に相当するものはありますか? または、ライブラリ自体から共有ライブラリの rpath を照会することは可能ですか?

編集: この投稿は、後者が可能であることを示唆しています。尋ねられた質問に対する答えを誰かが知っている場合に備えて、これを開いたままにします。Linux で現在の rpath を検査する方法はありますか?

やっています ...

しかし、エラーが発生し、その既存のパッケージは定義されていません

google-perfツール（tcmalloc）ライブラリを使用してPython 2.6.6をコンパイルし、デフォルトの2.6.5で発生していたメモリの問題の一部を排除しました。2.6.6を入手した後は、Ubuntuのデフォルトの2.6.5インストールに問題があるため、機能しないようです。wxPythonやsetuptoolsなどのソフトウェアチャネルからインストールされたバイナリは、2.6.6では正しく機能しません。これらを再コンパイルする必要がありますか？スムーズに機能させるためのその他の提案。パスを変更せずに2.6.5をデフォルトとして設定できますか？パスは最初にusr/local/binを調べます。

私は、おそらく非標準的な方法で、libtoolベースのパッケージを自分のプロジェクトに組み込んでみようとしています。これが私の目標です：

1. 外部プロジェクトを構築する：

   /li>

2. 実行時に外部プロジェクトの共有ライブラリと実行可能ファイルに依存する独自のプロジェクトをビルドします。

   /li>

3. すべてを単一の「ローカライズされた」tarballにパッケージ化します...つまり$HOME/blah、ビルドホストにすべてを入れている間に、環境に煩わされることなく、tarballを任意のディレクトリ（他のホスト）に抽出できるようにします。その目的は、私のプロジェクトの複数のバージョンを、厄介な「他家受粉」なしに並べて共存できるようにすることです。

プロジェクトに使用-rpath '$ORIGIN/../lib'して、実行時に適切な共有ライブラリが常に読み込まれるようにすることができます。-rpathただし、libtoolは、の正確なパスに基づいて独自の設定を割り当てることを主張しているようです$HOME/blah/lib。これは、すべてを別のディレクトリ（たとえば$HOME/blah.2011-06-02）に解凍すると壊れます。

この制限を回避する方法はありますか？このトピックについて、debianとlibtoolの人々の間でかなり長いrpathの議論が見られますが、それはやや古く、「私たちは同意しません」を超えて決定的ではありません。

-rpathGCC のリンカー (ld) でオプションを使用する方法を学習しようとしています$ORIGIN。

私が考えることができる最も単純な例を試しています（以下を参照）。私が読んだすべてのリンクは、私が正しくやっていると言っているようです。

ただし、実行可能ファイルを実行すると、 内から実行しない限り、共有オブジェクトが見つかりません$ORIGIN。

実行可能ファイル (main.run) で readelf -d を使用すると、次のように表示されます。

ファイル構造（関連ファイル）は次のとおりです。

• /make/test/dll_test/
  • main.run
  • lib/
    • foo.so

dll_test 内から実行すると正常に動作します。他の場所 (/make/test) から実行すると、次のエラーが発生します。

dll_test/main.run: 共有ライブラリの読み込み中にエラーが発生しました: lib/foo.so: 共有オブジェクト ファイルを開けません: そのようなファイルまたはディレクトリはありません

-l:foo.soの代わりにを使用していますが-lfoo、これは何にも影響しないはずです (願っています)。

ソースファイル

dll_test/src/foo.cpp

dll_test/src/main.cpp

ビルドスクリプト

dll_test/make.sh

ビルドするには、これらのファイルをそれぞれの場所に作成し、dll_test 内 (またはプロジェクトのルートがある場所) から "sh make.sh" を実行するだけです。「dll_test/main.run」が生成されます。

dll_test 内から "main.run" を実行すると動作するはずです (出力 1)。
dll_test 内から "main.run" を実行すると失敗します。なんで？

また、foo.so のパスは [lib/foo.so] として main.run に保存されます。-Wl,-rpath,'$ORIGIN/lib' を使用できるように [foo.so] にすることはできますか?

注：完全に機能する例を以下に示します。元の質問は次のとおりです。

ldの-rpathパラメータを。で使用すると問題が発生します$ORIGIN。
完全な例が見つからなかったので、後で自分や他の人が使えるように、自分で書いてみようと思いました。動作するようになったら、片付けます。

以前に質問しましたが、私の投稿は少し混乱していたと思います。

サンプルプロジェクトは、1つの共有ライブラリとそのライブラリにリンクする1つの実行可能ファイルをビルドします。
非常に小さいです（3ファイル、ビルドスクリプトを含む22行）。ここ
からプロジェクトをダウンロードできます

ファイル構造（ビルド前）：

• project/
  • src/
    • foo.cpp
    • main.cpp
  • make.sh

project/src/foo.cpp

project/src/main.cpp

project/make.sh

projectディレクトリから実行します（make.sh実行可能であることを確認してください）。

ファイル構造（ビルド後）：

• project/
  • src/
    • foo.cpp
    • main.cpp
  • obj/
    • foo.o
    • main.o
  • lib/
    • foo.so
  • run/
    • main.run
  • make.sh

run/main.runlib/foo.shこれで、どこからでも実行時にロードされるはずです。

問題

現在、これは部分的にしか機能しません。ファイルはコンパイルされ、リンクはOKですが、（演習のポイントである）
以外のディレクトリから実行するとリンクに失敗します。project

main.runショーでの検査readelf -d：
0x0000000000000001 (NEEDED) Shared library: [lib/foo.sh]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../../lib] どちらが近いように見えますか（私はむしろ持っていると思い[foo.sh]ます[lib/foo.sh]が、後で修正します）。

AFAICT $ORIGINinは、このrpathがになるようにすることを-Wl,-rpath,'$ORIGIN/../../lib'意味します。project/run/main.runproject/lib

私は、、、、無駄にしようとしました$ORIGIN/..。$ORIGIN/../lib$ORIGIN/../..$ORIGIN/../../lib

注：私は-l:完全なライブラリファイル名を必要とするものを使用しています（他の理由の中でも、すべての関数が同じ名前形式をとる場合、変数を使用してスクリプトを作成する方が簡単です）。

なぜこれが機能しないのか誰かが知っていますか？
または、代わりに、誰かが完全な実例を持っているか知っていますか？

ここでld の-rpathオプションを使用する基本的な例を作成しました(動作するバージョンについては、2 番目の応答を参照してください)。にリンクし、次に にリンクし、すべてとを使用する例を作成しようとしています。$ORIGIN main.runfoo.sobar.sorpath$ORIGIN

実行時のファイル構造は次のとおりです。

• 事業/
  • ライブラリ/
    • dir/
      • サブ/
        • bar.so
      • foo.so
  • 走る/
    • main.run (ビルドに失敗)

以下を使用して foo.so を構築しています。

これは問題なく構築されます。ldd lib/dir/foo.so見つけることさえできますbar.so。

しかし、 にリンクしようとするとmain.run、foo.sobar.sofoo.soが見つかりません。

以下を使用して main.so を構築しています。

foo.so再帰的にリンクしない別のバージョンの が使用されている場合、これは正常に機能します。(以下のプロジェクトの make.sh の行のコメントを外してテストします)。

ただし、通常の使用では、foo.soビルド時にこのエラーが発生しますmain.run:

/usr/bin/ld: 警告: lib/dir/foo.so に必要な bar.so が見つかりません (-rpath または -rpath-link を使用してみてください)

だから私の質問は：

1. foo.so$ORIGIN内ではproject/lib/dir(where foo.sois) またはproject/run(where main.run(リンクしている実行可能ファイル) is) に解決されますか?
   ldd は、それが であることを示しているように見えますがproject/lib/dir、これが最良の方法と思われます (ただし、両方を想定してみました)。
2. これらをリンクするにはどうすればよいですか（再配置可能性を維持しながら）-できれば-rpath-link.

プロジェクトはこちらからダウンロードできます。それは私がそれを作ることができるのと同じくらい簡単です。4 つの短いソースとスクリプト。
解凍後、./make.sh内から実行するだけproject/です。

注:を使用して-l:います。foo.soこれは、ライブラリの名前が ではなく のようになり、の代わりにでlibfoo.soランク付けされることを除いて、何も変更されません。-l:foo.so-lfoo

FreeBSD マシンで、実行時に libFoundation.so を見つける必要があるバイナリ「CeeloPartyServer」があります。どちらも同じディレクトリにあります。linker flag を使用して (別のプラットフォームで、クロス コンパイラを使用して) CeeloPartyServer をコンパイルします-rpath=$ORIGIN。

ライブラリを実行しようとしてもライブラリが見つからないのはなぜですか?

私の正確なリンカー行は次のとおり-lm -lmysql -rpath=$ORIGINです。

私のreadelf分析は実際にライブラリrpathが$ORIGINに設定されていることを示しているので、$などをエスケープする必要はないと確信しています。私は何が欠けていますか？

setcap CAP_NET_RAW を有効にして Python を使用しています。私の python スクリプトは、RPATH に $ORIGIN を持つ共有ライブラリをインポートします。私の python は現在 suid アプリであるため、 $ORIGIN は評価されず、ライブラリは正しく読み込まれません (これはglibc で見つかったセキュリティ リークが原因です)。私のライブラリパスが安全であることをリンカに伝え、ライブラリをロードする方法はありますか?

さらにいくつかのメモ：

1. この機能は開発段階でのみ必要です。私は生産ソリューションを探していません。
2. ルートとして作業すると、すべてが機能します。
3. 私はルートとして働きたくありません。

ありがとう、デイブ

便宜上、以下に関連するマンページを追加しました。

私の（誤）最初の理解：オプションをで区切る必要がある場合、それは2番目がオプションの引数であることを意味する前にあるため,、2番目は別のオプションではないことを意味します。-Wl,-rpath

どうすれば議論-rpathできるのかわかりません！-Wl,.

私の頭の中で理にかなっているのはこれでしょう：

これ-rpathにより、現在のディレクトリ引数を使用してリンカーオプションが呼び出されます。

man gcc：

-Wl、オプション

オプションとしてオプションをリンカに渡します。オプションにコンマが含まれている場合、コンマで複数のオプションに分割されます。この構文を使用して、オプションに引数を渡すことができます。たとえば、リンカーに-Wl,-Map,output.map渡し ます。-Map output.mapGNUリンカを使用する場合、 `-Wl、-Map =output.map'でも同じ効果を得ることができます。

男ld：

-rpath = dir

ランタイムライブラリの検索パスにディレクトリを追加します。これは、ELF実行可能ファイルを共有オブジェクトにリンクするときに使用されます。すべての-rpath引数は連結され、実行時リンカーに渡されます。実行時リンカーは、それらを使用して実行時に共有オブジェクトを検索します。-rpathオプションは、リンクに明示的に含まれている共有オブジェクトが必要とする共有オブジェクトを見つけるときにも使用されます。