4

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

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

    ./configure --prefix=$HOME/blah --etcetera && make && make install

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

    gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program

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

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

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

4

1 に答える 1

1

ここでdebianWikiのRpathissueに示されているオプションの中chrpathで、「インストール」ステップまたは後処理スクリプトで使用することは、実行可能なオプションのように聞こえます。（お気に入りのパッケージマネージャーを介して、多数のディストリビューションで利用できます。）

libtoolプラスIMOであるパッチ適用は必要ありません。

いくつかの制限があることに注意してくださいrpath。元のファイルよりも短い（または同じ長さの）場合にのみ、新しいファイルを保存できます。

もう1つの（実用的な）オプションは、rpath（chrpathがそれを実行できる）を削除LD_LIBRARY_PATHし、アプリに必要なものに設定するラッパースクリプトを用意することです。これは、移植性が少し高くなる可能性もあります（一部のOSにある他の共有ライブラリパス環境変数を処理する場合）。

于 2011-06-03T06:04:46.030 に答える