ldd コマンドは、Linux で実行ファイルや共有ライブラリが動作時にリンクする共有ライブラリ（依存ライブラリ）の一覧を表示するためのコマンドです。
「このプログラムを動かすためにどのライブラリが必要か」を調査するときに使われます。
共有ライブラリとは
共有ライブラリ（Shared Library）とは、複数のプログラムが共通して利用できるライブラリファイルのことです。Linux では .so（Shared Object）という拡張子を持ちます。
たとえば C の標準ライブラリ libc.so.6 は、ほぼすべての Linux プログラムが依存しています。共有ライブラリを使う方式を「動的リンク」と呼び、プログラム起動時に必要なライブラリが読み込まれます。
構文（Syntax）
ldd [オプション] 実行ファイル...
主なオプション一覧
| オプション | 説明 | 使用例 |
|---|---|---|
| (なし) | 依存する共有ライブラリを一覧表示 | ldd /bin/ls |
-v | 詳細モード（すべてのバージョン情報を表示） | ldd -v /bin/ls |
-u | 未使用の直接依存ライブラリを表示 | ldd -u /usr/bin/ssh |
--version | ldd のバージョンを表示 | ldd --version |
基本の使い方
実行ファイルの依存ライブラリを確認する
ldd /bin/ls
出力例:
linux-vdso.so.1 (0x00007ffc4f5d9000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6d4f3a7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6d4efd6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6d4f5e9000)
詳細モードで確認
ldd -v /bin/ls
未使用ライブラリの確認
ldd -u /usr/bin/ssh
出力例:
Unused direct dependencies:
/lib/x86_64-linux-gnu/libcrypto.so.1.1
出力結果の読み方
ldd /bin/ls の出力例を使って各フィールドの意味を説明します。
linux-vdso.so.1 (0x00007ffc4f5d9000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6d4f3a7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6d4efd6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6d4f5e9000)
| フィールド | 説明 |
|---|---|
ライブラリ名（例: libc.so.6） | 依存している共有ライブラリの名前 |
=> の右側のパス | 実際にファイルシステム上で見つかったライブラリのパス |
(0x...) のアドレス | プロセスのメモリ空間にマップされたアドレス |
linux-vdso.so.1 | カーネルが提供する仮想ライブラリ（ファイルとして存在しない） |
not found | ライブラリがシステム上で見つからない状態（後述） |
not found が表示された場合
ライブラリが見つからないと、次のように not found が表示されます。
libfoo.so.1 => not found
これは、依存しているライブラリがシステム上に存在しない、またはダイナミックリンカが見つけられない状態を意味します。
このような実行ファイルを起動しようとすると、以下のようなエラーが出て起動に失敗します。
./myapp: error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory
原因と対処の流れ:
- まず
ldd 実行ファイルでnot foundになっているライブラリ名を確認する - そのライブラリがシステムにインストールされているか確認する（
dpkg -l | grep libfooやrpm -qa | grep libfooなど） - インストールされていなければパッケージをインストールする
- インストール済みでも
not foundになる場合は、ライブラリのパスがLD_LIBRARY_PATHやldconfigのキャッシュに登録されていない可能性がある
LD_LIBRARY_PATH との関係
LD_LIBRARY_PATH は、共有ライブラリの検索パスを追加するための環境変数です。not found になるライブラリが特定のディレクトリに存在する場合、LD_LIBRARY_PATH を設定することで一時的に解決できます。
# /opt/myapp/lib にライブラリがある場合
export LD_LIBRARY_PATH=/opt/myapp/lib:$LD_LIBRARY_PATH
# 設定後に ldd で確認
ldd /opt/myapp/bin/myapp
ただし、LD_LIBRARY_PATH の設定は一時的な対処であり、セキュリティ上のリスクもあるため、本番環境では ldconfig による恒久的な設定が推奨されます。
ldconfig との関係・共有ライブラリの検索パスを確認する
ldconfig は、共有ライブラリのキャッシュ（/etc/ld.so.cache）を更新・管理するコマンドです。ダイナミックリンカはこのキャッシュを参照してライブラリを高速に検索します。
ライブラリのロードパスは以下の順序で決まります:
- 実行ファイルに埋め込まれた rpath/runpath
- 環境変数
LD_LIBRARY_PATH /etc/ld.so.cache（ldconfigが管理）- デフォルトディレクトリ（
/lib、/usr/lib、/lib64など）
新しいライブラリをインストールした後や、/etc/ld.so.conf にパスを追加した後は sudo ldconfig を実行してキャッシュを更新します。
# /etc/ld.so.conf.d/ にカスタムパスを追加してキャッシュ更新
echo "/opt/myapp/lib" | sudo tee /etc/ld.so.conf.d/myapp.conf
sudo ldconfig
# キャッシュに登録されているライブラリ一覧を確認
ldconfig -p
# 特定のライブラリを検索
ldconfig -p | grep libfoo
ldd と ldconfig の違い:
| コマンド | 役割 |
|---|---|
ldd | 特定の実行ファイルが必要とするライブラリとその解決状況を表示する |
ldconfig | システム全体のライブラリキャッシュを更新・管理する |
実行ファイルが起動できない場合の調査例
プログラムを起動しようとして「shared libraries: cannot open shared object file」などのエラーが出た場合の調査手順です。
# ① ldd で not found になっているライブラリを確認
ldd /usr/local/bin/myapp
# 出力例（not found があれば問題のライブラリがわかる）
# libcustom.so.2 => not found
# libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f...)
# ② そのライブラリがどこにあるか探す
find / -name "libcustom.so*" 2>/dev/null
# ③ 見つかったパスを ldconfig に登録するか LD_LIBRARY_PATH に追加
export LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH
# ④ 再度 ldd で解決できたか確認
ldd /usr/local/bin/myapp
Docker やサーバー環境での依存ライブラリ確認
Docker コンテナや最小構成のサーバー環境では、必要なライブラリが揃っていないことが多いため、ldd を使った事前確認が重要です。
# コンテナ内でバイナリをコピーする前に依存関係を確認
ldd /usr/local/bin/myapp
# not found があれば、Dockerfile でインストールするパッケージを追加
# 例: libssl1.1 が not found の場合
# RUN apt-get install -y libssl1.1
また、コンパイルした環境と実行環境でライブラリのバージョンが異なるケースもあります。ldd -v で必要なバージョン情報も確認できます。
# バイナリをサーバーにコピーした後に依存関係を確認
scp myapp user@server:/tmp/
ssh user@server "ldd /tmp/myapp"
静的リンクされたバイナリの場合
静的リンクされたバイナリは、実行に必要なすべてのコードを自分自身の中に含んでいるため、共有ライブラリへの依存がありません。ldd を実行すると次のように表示されます。
ldd /bin/busybox
not a dynamic executable
Go や Rust で CGO_ENABLED=0 でビルドしたバイナリや、musl を使って静的リンクしたバイナリはこのように表示されます。こうしたバイナリは Docker の scratch イメージなどライブラリが一切ない環境でも動作します。
セキュリティ上の注意点
ldd は内部的にダイナミックリンカ（ld-linux.so）を呼び出してライブラリを解決します。これは実際にプログラムの一部のコードが実行される可能性があることを意味します。
信頼できない実行ファイルに対して ldd を実行しないでください。悪意を持って作成されたバイナリは、ldd の実行をトリガーにして任意のコードを実行する可能性があります。
安全に解析する方法:
# ldd の代わりに objdump や readelf を使う（コードは実行されない）
objdump -x /path/to/unknown-binary | grep NEEDED
readelf -d /path/to/unknown-binary | grep NEEDED
これらのコマンドは ELF ファイルをそのまま解析するため、コードが実行される心配がありません。
実行例（その他）
存在しないファイルを指定（エラー例）
ldd notfound
ldd: notfound: No such file or directory
実行ファイルでないファイルを指定した場合
ldd /etc/passwd
not a dynamic executable
よくある疑問
ldd は何を確認するコマンドか
実行ファイルが動作するために必要な共有ライブラリ（.so ファイル）の一覧と、それらがシステム上で実際に解決できるかを確認するコマンドです。
not found はどう直すか
まず ldd で not found になっているライブラリ名を確認します。次にそのライブラリのパッケージをインストールするか、ライブラリファイルが存在するパスを LD_LIBRARY_PATH や /etc/ld.so.conf に追加してから sudo ldconfig でキャッシュを更新します。
共有ライブラリの場所はどこで確認するか
ldconfig -p でシステムに登録されているライブラリの一覧とパスを確認できます。また find / -name "libname.so*" でファイルシステム全体から検索することもできます。
ldd と ldconfig は何が違うか
ldd は「特定の実行ファイルが必要とするライブラリを確認する」読み取り専用のコマンドです。ldconfig は「システム全体のライブラリキャッシュを更新・管理する」管理コマンドです。
シェルスクリプトに対して使えるか
使えません。ldd は ELF 形式のバイナリに対してのみ有効です。シェルスクリプトはテキストファイルであり共有ライブラリを直接リンクしていないため、not a dynamic executable が返ります。スクリプト内で呼ばれているコマンドの依存ライブラリを確認したい場合は、各コマンドのパスに対して個別に ldd を実行します。
関連コマンド
ldconfig: ライブラリキャッシュを更新・管理readelf -d: ELF バイナリの動的セクションを確認objdump -x: 実行ファイルやライブラリの詳細情報を表示
参考
- manページ: man7.org ldd(1)
- GNU C Library: https://www.gnu.org/software/libc/
コメント