問題タブ [ldd]

LinuxでC++実行可能ファイルを作成しています。実行可能ファイルは、いくつかのBoostライブラリにリンクしています。

これは、バイナリを実行しようとしたときの出力です。

次に、バイナリでlddを実行して、依存関係を確認します。

liboos_system.sl.1.45.0SOが見つからない理由がわかりません。今日は少し前にうまく構築しました。誰か説明できますか？

私はかなりの数のライブラリに依存する C++ プログラムを持っています (libjpeg のようないくつかの一般的なシステム ライブラリは、システム全体にインストールされていないいくつかの個人用ライブラリです)。プログラムは、マシン A (Debian Squeeze) で適切にコンパイルされます。マシン B (Ubuntu maveric) とマシン C (Arch) でプログラムを実行したいと思います。両方のマシン B+C が非常に最小限のインストールであると仮定します。私のプログラムがそこで使用するライブラリを見つけることを期待しないでください。もしあれば、それらは同じバージョンではありません。

プログラムをスキャンしてすべての依存関係を (ldd などを使用して) 調べ、それらのすべての依存関係を収集し、バイナリにこれらと他のシステムに付属するこれらのライブラリのみを使用するように指示するスクリプトを生成できるプログラムはありますか?

ありがとうございました ！

現在、Eclipse 内で実行されているプログラムがあり、システム上の別の共有オブジェクトのラッパーとして作成した共有オブジェクトへの JNI 呼び出しを使用しています。これは、Eclipse 内から実行すると問題なく動作しますが、次のコマンドを使用してコマンド ラインから実行すると、ラッパーが呼び出す共有オブジェクトが未定義のシンボル エラーをスローします。

java -Djava.library.path=[ライブラリへのパス] com.[私の名前].[プログラム]

ldd は、共有オブジェクトにライブラリが欠落していることを示していないようです。また、シェルですべての環境変数を設定して、Eclipse環境と同じように実行しようとしましたが、同じことを行います。ここからどこへ行くべきかについての提案は大歓迎です。私はアイデアがありません。

ご協力ありがとうございました

に依存していることをどのようにldd知るのですlibc.so.6か?libc.so.5libc.so.7

64 ビット CentOS 5.5 に Python 2.7.1 をインストールし、2.7.1 に対して mod_wsgi をコンパイルしました。私は DJango Web アプリケーションを構築しており、2.7 からの Python モジュールが必要です (Python の CentOS 組み込みバージョンは 2.4.3 しかなく、ひどく不足しています)。私は基本的にこの素晴らしいリンクの手順に従いました：

http://willsani.com/2011/03/02/centos-5-5-x86_64-install-python-2-7/

これで、Python 2.7.1 の動作バージョンが /opt/python2.7.1 にインストールされました。しかし、mod_wsgi.o モジュールを Apache にインストールすると、Apache の起動に失敗します。

そのため、自分のバージョンの mod_wsgi.o に対して ldd コマンドを実行すると、予想される共有ライブラリのリストが表示される代わりに、次のように表示されます。

現在、私の Web アプリケーションは mod_wsgi で実行されており、Python 2.4.3 に対して正常に動作しています。他の誰かがそれを設定したので、何か特別なことをする必要があるかどうかはわかりません - 私は設定を継承しました。http://code.google.com/p/modwsgi/から mod_wsgi のビルドとインストールに関連するすべてを読み、Web で回答を検索しました。このエラーで何も見つかりません。

どんな助けでも大歓迎です！

クロスコンパイルされたarm実行可能ファイルを作成しました。実行可能ファイルのライブラリ依存関係を見つけたい。私はubuntunattyを使用しており、lddを含まないarm-linux-gnueabiツールチェーンをインストールしています。Linuxでarm実行可能ファイルライブラリの依存関係を表示するために利用できるツールはありますか？

この見つからないライブラリの問題を解決するためのヒントはありますか? この場合、ソースからコンパイルするのではなく、Sunfreeware パッケージを使用しています。

- - より詳しい情報 - -

--- 汚れた回避策 ---

--- 別の試みは失敗します ---

pf_ring でコンパイルされた libpcap を使用しようとしています。ntop からソースを取得し、コンパイルしました。

ただし、理解できないことがあります (初心者のリンクの質問で申し訳ありません): アプリケーションが正しい pcap バージョン (pfring を使用したもの) を使用しているかどうかを知りたかったので、ldd と入力しましたが、pcap がまったく表示されませんでした。フリングのみ。

両方のライブラリに動的にリンクしていましたが、出力を確認したところ、pcap ではなく pfring.so しか表示されませんでした。

libpcap の Makefile を見ると、pfring.a と静的にリンクされていることがわかりました。pfring は pcap の一部であるため、リンクする必要はまったくないと思っていましたが、未定義の参照がありました。

未定義の参照エラーが発生する理由と、動的にリンクしたときにldd出力にlibpcapが表示されない理由を知っている人はいますか?

ありがとう、ロン

たとえば、2 つのトースター ライブラリlibtoaster_a.soとlibtoaster_b.soと、関連するすべてのメジャー/マイナー/リビジョン シンボリック リンク(libtoaster_a.so.1.0.0など) など、2 つのライブラリがあります。どちらのライブラリも同じトースター インターフェイスを実装していますが、単に処理を行うだけです。違う。したがって、ライブラリを使用するアプリケーションを構築する場合、どちらを使用しても問題ありません (アプリケーションの観点からは、それらは同じです)。

アプリケーションをコンパイルして配布した後で、使用するライブラリを決定したいので、libtoaster.so.1 を指すシンボリックリンクlibtoaster.soを作成します。 1 . したがって、ユーザー/インストーラーはlibtoaster.so.1リンクを変更するだけで、使用する実装を選択できます。

ビルドでは、デフォルトで libtoaster.so.1 がlibtoaster_a.so.1にリンクされているとします。アプリケーションをコンパイルすると、たとえばmy_appのようなものがコンパイルされ、 libtoaster_a.so.1で正しく実行されます。ただし、ldd を my_app で実行すると、必要に応じてlibtoaster.so.1ではなくlibtoaster_a.so.1にリンクされていることがわかります。したがって、 libtoaster.so.1リンクを変更しても効果はありません。gcc -o my_app -ltoaster...

libtoaster_a.so.1 を作成し、名前をlibtoaster.so.1に変更し、 このライブラリに対してmy_appを作成してからlibtoaster.so.1を削除し、シンボリック リンクとして再度作成するよりも、これを修正する良い方法はありますか?

パスのリストを取得するための最もポータブルで堅牢な方法は何/etc/ld.so.confですか？それによって構成され、そこから含まれるファイルは何ですか？ファイルを手動で解析することはお勧めできません—フォーマットは将来のリビジョンで変更される可能性があります。

質問をよりよく理解できるように、以下に具体的な詳細を示します。これらの詳細にもかかわらず、これは一般的なプログラミングの質問であり、他の状況に適用できることに注意してください。

LuaRocksと呼ばれるプログラムがあります。これは、Luaプログラミング言語（Ruby gemやPythoneggsのようなもの）のパッケージマネージャーです。LuaRocksパッケージは「ロック」と呼ばれます。

便利な機能として、LuaRocksを使用すると、ロックの作成者は、Cヘッダーファイルやダイナミックライブラリファイルのリストとして作成された、ロックの外部依存関係のリストを指定できます。（Linuxでは.so。）指定されたファイルが存在しない場合、ロックをインストールできません。

現在、Linuxでは、LuaRocksはデフォルトで2つのハードコードされたパスでファイルを検索することによって.soファイルの存在をチェック/usr/libします/usr/local/lib。

これは間違った振る舞いであり、Ubuntuや他のDebianディストリビューションの最近の変更によって壊れていると思います。

更新：パス自体はハードコーディングされていませんが、構成ファイルでユーザーが構成できます。それでも、IMOは最善の解決策ではありません。

代わりに（私が理解しているように）、LuaRocksは、パスで指定された/etc/ld.so.confファイルとそこに含まれるファイルを検索する必要があります。

（今、上記の質問をもう一度読んでください;-)）