問題タブ [ldd]

CentOS5 を使用しており、必要なスクリプトをインストールしようとしていますldd。

私はもう試した：

最初の 2 つは既にインストールされていると言いますが、後者は明らかにエラーなしで再インストールされます。

だから私の問題は、私が使用しているスクリプト（AVS）がまだlddバイナリが見つからないと主張していることです。

インストールするデフォルトのディレクトリはありますか? 次のファイルがあります。

/usr/bin と /usr/local/bin の両方

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

boost_system共有オブジェクトを使用するサンプルアプリケーションがあります。ここで、特定のシナリオのために、2つの異なるboost_system共有オブジェクトをサポートする必要があります。1つはgccで構築され、もう1つは単一ディレクトリにsunのccで構築されます-/ home/mydir。対応するファイルは次のとおりです。-

これは、makefileでとしてリンクされています。

したがって、libboost_system_1_41_0.soの名前をlibboost_system_v1.soに変更し、$ BOOST_HOME_V1 / stage/libからソフトリンクも削除しました。さて、アプリケーションをビルドしようとすると、エラーは発生しません。ただし、lddは次の場合に失敗します：-

BOOST_HOME_v1 / stage / lib（= BOOST_LIB_v1）は次のようになります：-

理解できません-なぜldDはlibboost_system_v1.soではなくlibboost_system.so.1.41.0を依存関係として表示するのですか？

私は以下のo/pを見ることを期待していましたが、これは得られたものではありません：-

誰かが実際に共有オブジェクトの名前を変更し、boostのデフォルトのシンボリックリンクを処理しない解決策があるかどうか説明できますか？src / build.jamをチェックしました-ここでリンクが行われているようです-しかし、ソフトリンクを削除し、共有オブジェクトの名前を変更し、makefileで名前を変更した共有オブジェクトにリンクする限り、問題はないはずです。

ldd次のような共有ライブラリに対して実行すると、次libphp5.soの依存関係があることがわかりますlibmysqlclient.so.16。

これらの依存ファイル名とパス ( /usr/lib/mysql/libmysqlclient.so.16) は、共有ライブラリ バイナリに組み込まれていますか? または、このパスは via などの他の手段によって決定されますが/etc/ld.so.conf.d/mysql-i386.conf、これには次のものが含まれています。

もう1つのことが私を困惑させています：

ソースからコンパイルした共有ライブラリがあります。これは に依存していlibmysqlclient_rます。コンパイラはgcc、このライブラリを次のように生成するように切り替えます。

私がldd mylib.so見るとき：

ただし、/usr/lib/mysqlディレクトリには次のように表示されます。

libmysqlclient_r.soは へのシンボリック リンクなので、依存関係が として表示されるのはlibmysqlclient_r.so.16.0.0なぜですか。ここで私が見逃している魔法はありますか？lddlibmysqlclient_r.so.16

_{長年 Windows 開発者として働いてきた私は、gccLinux の開発に少し慣れていません。}

私の Linux ディストリビューションは CentOS 6.0 x86-32bit です。

Linux（Ubuntu 11）で2つの共有ライブラリ（ "A"、 "B"）をコンパイルしています

lib "B"は、lib "A"からエクスポートされた関数を使用しています（-lAで静的にリンクされています）

しかし、私が「B」でlddを実行しているとき、私はただ持っています*

「A」の依存関係が表示されません！？

奇妙なことに、私は（ほぼ）lddがすべての静的依存関係を表示するために使用されていることをかなり確信していました！？

sdb に非常に最小限の chroot 環境を作成し、にマウントしました/mnt/sdb。へのシンボリックリンクも作成しまし/mnt/sdb/bin/ccた/usr/bin/gcc。

ldd /mnt/sdb/bin/cc戻ってきた

そこで、次を実行して必要なライブラリをコピーしました。

この記事をざっと見てみるlinux-gate.so.1と、 はカーネルの一部であるため、コピーする必要がないことがわかりました。

ただし、実行したchroot /mnt/sdb /bin/sh後、試しccてみてください

ldd が cc に必要な libm.so.6 を通知できなかったのはなぜですか? すべてのライブラリを単純にコピーすることなく、chroot 環境で cc を動作させる簡単な方法はありますか? 一時的に cc を使用して、それを使用して tcc をビルドし、それから tcc を使用して他のすべてをビルドできるようにしたいだけです (単純に tcc を外部でビルドしてから chroot で使用することも試みましたが、その価値があるのではないかと心配しています)。自分の投稿）。

ノート：

私は Virtualbox で Debian を使用していますが、chroot 環境で現在実行されている唯一のプログラムは、単一の (静的) ビジーボックス バイナリです。

NetCDF C ++ライブラリを使用して構築しているアプリケーションがあり、NetCDFはHDF-4ライブラリをプルしています。ただし、間違ったHDF-4ライブラリを取得しています。

これが私のアプリがどのようにリンクされているかです：

LD_LIBRARY_PATHを非常に短く設定しました。

そして、これがldd-v出力からの抜粋です。

これまでのところ、LD_LIBRARY_PATH、rpath、およびlddのすべては、参照するHDF（/new_apps1/hdf4/lib/libmfhdf.so.0）を指していることを示しています。しかし、私が実行すると、Valgrindは、リンクしようとしているHDF-4ライブラリではなく、古いHDF-4ライブラリで死にかけていると言っています（これがおそらくsegfaultingである理由です）。

他のライブラリを動的にプルするときに、アプリがパス情報を取得する場所は他にありますか？

壊れた PyV8 インストールのトラブルシューティングを行っていてldd、これまでに見たことのないコマンド/プログラムの使用に関するオンライン フォーラムでの議論に気付きました。

それは何ですか、どこで入手できますか?

これが私が見つけた議論です：http://groups.google.com/group/pyv8/browse_thread/thread/c14330fe431a69a7?pli=1

質問の短いバージョン： gdbにデバッグシンボルを使用させるにはどうすればよいlibcですか？

長いバージョン： gdbを使用してプログラムをデバッグしていて、によって使用されるfutexに関する情報を確認したいlibc。ただし、デバッグ中のある時点で、次のような出力が得られます。

info sharedlibraryブレークポイントでgdbを実行すると、次のように表示されます。

そして私が走るlddと私は見る：

私はUbuntu10.04を使用していますが、libcデバッグシンボル付きのバージョンはにあると思います/usr/lib/debug/lib。パスの先頭にこれを配置するように変数を設定しようとLD_LIBRARY_PATHしましたが、違いは見られませんでした。

プログラムがロードする共有ライブラリをどのように選択するか、これが実行時に設定されるのかコンパイル時に設定されるのか、完全にはわかりません（私は実行時を想定していますが、今はわかりません）。したがって、gdbにのデバッグバージョンを使用させる方法に関する情報をいただければ幸いlibcです。

ldd特定の実行可能ファイルが使用している、または使用する予定の共有ライブラリをチェックする簡単な方法です。ただし、常に期待どおりに機能するとは限りません。たとえば、次のシェル スニペットを参照してください。これは、python バイナリへの libreadline の「依存関係」がどのように「失敗」するかを示しています。

他の多くのディストリビューションを試しましたが、Tikanga からコピーしています

lddデフォルトでインストールされているものを確認してくださいpython（公式リポジトリから）。

readline について何も見つかりませんでした。インタラクティブな使用法から、このバイナリには実際の機能があることがわかりました。

バックグラウンドでインタラクティブな Python セッションを開始しました (pid 21003)

ビンゴ！こちらがreadlineです！

ただし、この手法はライブラリが効果的にロードされている場合にのみ機能するため、たとえば/usr/lib64/libtcl8.4.so、python プロセスが次のようなものを実行しないまで検出されません。from Tkinter import *

だから私は2つの質問があります：

1. 問題lddは、標準ローダーの使用を想定していることだと思いますが、Pythonは独自の特別なローダーを使用している可能性が非常に高いです（純粋ではない新しいpythonモジュールをインストールするたびに実行可能ファイルを再リンクする必要はありませんpython ですが、いくつかの c/c++/fortran コードがあります)。これは正しいです？

2. 明らかに、実行可能ファイルが独自のローダーを使用している場合、「この実行可能ファイルがロードする可能性のあるすべてのライブラリを見つける方法」という質問に対する明確な答えはありません。それは、ローダーが何をするかに依存します。しかし、どのライブラリが python によって読み込まれるかを調べる方法はありますか?

PS：1に関連しています。この質問に到達している場合は、次のことをすでに知っている必要がありますが、そうでない場合は、出力を完全に台無しにするのがいかに簡単かを確認してくださいldd（部分的にのみ台無しにするのは少し難しいです）：