このエラーに初めて遭遇すると、何が起きているのかわからず途方に暮れてしまいます。
原因はほとんどの場合、共有ライブラリ（.so ファイル）が見つからないことです。
そしてその調査に使うのが ldd コマンドです。
この記事では、ldd コマンドの基本的な使い方から、「not found」エラーの原因特定手順、ldconfig によるライブラリパスの更新まで解説します。
RHEL 9 / Rocky Linux 9 / Ubuntu 24.04 LTS 環境で動作確認済みです。
この記事のポイント
・ldd コマンドで実行ファイルが必要とする共有ライブラリ一覧を確認できる
・「not found」表示は ldconfig や LD_LIBRARY_PATH で解決できる
・readelf -d でより安全にライブラリ依存を確認する方法もある
・ldconfig -v でライブラリキャッシュを更新すれば /usr/local/lib 配下も認識される
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
ldd コマンドとは何か
ldd は「list dynamic dependencies」の略で、ELF 形式の実行ファイルや共有ライブラリが依存している共有ライブラリの一覧を表示するコマンドです。Linux のコマンドや実行ファイルの多くは、すべての処理を自前で持っているわけではありません。
標準 C ライブラリ（glibc）やネットワーク関連ライブラリ、SSL ライブラリなど、他の .so ファイルに処理を「委託」しています。
この委託先のファイルを「共有ライブラリ（shared library）」と呼びます。
ldd を使うと、「このコマンドは起動するときに、どの .so ファイルを読み込む必要があるか」を一覧で確認できます。
なお、ldd は単独のコマンドではなく、シェルスクリプトとして実装されています。
内部的には
LD_TRACE_LOADED_OBJECTS=1 という環境変数を設定して実行ファイルを起動することで、ダイナミックリンカーにライブラリ一覧を出力させる仕組みです。基本的な使い方
1. 実行ファイルの依存ライブラリを確認する
引数に実行ファイルのパスを指定するだけです。# ldd /bin/ls linux-vdso.so.1 (0x00007ffd2b5c1000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8a3d120000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f8a3d118000) libc.so.6 => /lib64/libc.so.6 (0x00007f8a3cf00000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f8a3ce6a000) /lib64/ld-linux-x86-64.so.2 (0x00007f8a3d177000)
・ライブラリ名 => パス (アドレス)：そのライブラリが見つかった場合の表示
・ライブラリ名 => not found：ライブラリが見つからない場合の表示（問題あり）
・linux-vdso.so.1：カーネルが提供する仮想ダイナミックリンクライブラリ（常に表示される）
・/lib64/ld-linux-x86-64.so.2：ダイナミックリンカー本体（ローダー）
2. 「not found」が出た場合を確認する
インストールしたばかりのソフトウェアや、ソースからコンパイルしたコマンドを実行した際にエラーが出る場合、ldd で状況を確認できます。# ldd /usr/local/bin/myapp linux-vdso.so.1 (0x00007ffcf9d8b000) libcrypto.so.3 => not found libssl.so.3 => not found libc.so.6 => /lib64/libc.so.6 (0x00007f3b4e200000) /lib64/ld-linux-x86-64.so.2 (0x00007f3b4e490000)
not found と表示された libcrypto.so.3 と libssl.so.3 が見つかっていません。この状態で実行しようとすると、冒頭で紹介した「error while loading shared libraries」エラーが発生します。
3. 共有ライブラリ自体の依存関係を確認する
ldd は実行ファイルだけでなく、.so ファイルに対しても使えます。# ldd /lib64/libssl.so.3 linux-vdso.so.1 (0x00007ffc489b2000) libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f2a8e200000) libc.so.6 => /lib64/libc.so.6 (0x00007f2a8e000000) /lib64/ld-linux-x86-64.so.2 (0x00007f2a8e7e4000)
「not found」エラーを解決する方法
1. パッケージのインストールで解決する（最も確実な方法）
まず、not found になったライブラリを提供するパッケージを探してインストールします。RHEL 9 / Rocky Linux 9 の場合:
# dnf provides libssl.so.3 # dnf install openssl-libs
# apt-file search libssl.so.3 # apt install libssl3
2. ldconfig でライブラリキャッシュを更新する
ソースからコンパイルしたライブラリを/usr/local/lib 配下に置いた場合など、パスが通っていても ldconfig のキャッシュに登録されていないことがあります。# ldconfig
ldconfig が参照するパスは
/etc/ld.so.conf と /etc/ld.so.conf.d/ 配下のファイルで定義されています。/usr/local/lib がリストに含まれているか確認しましょう。# cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf # cat /etc/ld.so.conf.d/local.conf /usr/local/lib /usr/local/lib64 # ldconfig # ldconfig -v 2>/dev/null | grep mylib
/usr/local/lib が ld.so.conf に含まれていなければ、追加してから ldconfig を再実行します。3. LD_LIBRARY_PATH で一時的に解決する（開発・テスト用途）
本番環境では使用しないほうがよいですが、開発やテストの場面ではLD_LIBRARY_PATH 環境変数を使う方法もあります。# export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH # ldd /usr/local/bin/myapp
LD_LIBRARY_PATH を使うのは避けてください。意図しないライブラリが読み込まれるセキュリティリスクや、他のコマンドの動作に影響するトラブルの原因になります。
応用・実務 Tips
1. readelf -d でより安全に依存関係を確認する
ldd は実際に実行ファイルを（トレースモードで）起動するため、悪意のあるバイナリに対して実行するとコードが動いてしまうリスクがあります。信頼できないバイナリを調査する場合は
readelf -d を使う方が安全です。# readelf -d /bin/ls | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] 0x0000000000000001 (NEEDED) Shared library: [libcap.so.2] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
readelf -d は ELF ヘッダーを読むだけなので、バイナリを実行しません。ただしパスの解決（実際に存在するかどうか）は確認できないため、ldd と使い分けましょう。
2. ldconfig -p で登録済みライブラリを一覧表示する
システムに登録されているライブラリを確認したい場合はldconfig -p が便利です。# ldconfig -p | grep libssl libssl.so.3 (libc6,x86-64) => /lib64/libssl.so.3 libssl.so.1.1 (libc6,x86-64) => /lib64/libssl.so.1.1
not found になっているライブラリ名で ldconfig -p | grep して存在を確認し、見つかればパスの問題であり ldconfig で解決できます。全く見つからなければパッケージのインストールが必要です。
3. 複数バイナリをまとめて確認する
find と組み合わせると、指定ディレクトリ配下の全実行ファイルを一括チェックできます。# find /usr/local/bin -type f -executable | xargs -I{} ldd {} 2>&1 | grep "not found"
/usr/local/bin 配下でライブラリが不足している実行ファイルを一括で洗い出せます。ソースからコンパイルして大量に配置した後の確認作業に重宝します。
なお
xargs コマンドについては xargsコマンドで標準入力からコマンドを一括実行する方法 で詳しく解説しています。4. 静的リンクバイナリの判別
# ldd /bin/busybox not a dynamic executable
Go 言語でコンパイルされたバイナリや、Docker コンテナ向けに作られた最小構成のバイナリがこのパターンになることがあります。
トラブルシュート・エラー対処
「error while loading shared libraries」が解消しない場合
ldconfig を実行しても解決しない場合は、以下の順番で確認してください。手順1: ライブラリファイルが実際に存在するか確認する
# find /usr -name "libssl.so.3" 2>/dev/null # find /usr/local -name "libssl.so.3" 2>/dev/null
共有ライブラリはバージョン番号付きのファイル（例:
libssl.so.3.0.7）とシンボリックリンク（libssl.so.3）で管理されます。リンクが切れていることがあります。
# ls -la /lib64/libssl.so* lrwxrwxrwx. 1 root root 14 Jan 15 09:00 /lib64/libssl.so.3 -> libssl.so.3.0.7 -rwxr-xr-x. 1 root root 718432 Jan 15 09:00 /lib64/libssl.so.3.0.7
64bit バイナリが 32bit ライブラリを要求するケース（またはその逆）では、ライブラリが存在してもエラーになります。
file コマンドで確認しましょう。# file /usr/local/bin/myapp /usr/local/bin/myapp: ELF 64-bit LSB executable, x86-64 ... # file /usr/local/lib/libmylib.so.1 /usr/local/lib/libmylib.so.1: ELF 32-bit LSB shared object, Intel 80386 ...
「ldd: exited with unknown exit code (127)」が出た場合
実行ファイルが 32bit バイナリで、32bit のダイナミックリンカー（/lib/ld-linux.so.2）が存在しない場合に発生します。# RHEL 9 / Rocky Linux 9 の場合 # dnf install glibc.i686 # Ubuntu 24.04 の場合 # dpkg --add-architecture i386 # apt install libc6:i386
古い商用ソフトウェアを動かす際などに遭遇するパターンです。
本記事のまとめ
ldd コマンドは、共有ライブラリの問題を素早く切り分けるための重要なツールです。「コマンドが実行できない」「インストール後にエラーが出る」という状況では、まず ldd で依存関係を確認する習慣をつけましょう。
| やりたいこと | コマンド |
|---|---|
| 実行ファイルの依存ライブラリを確認する | ldd /path/to/binary |
| not found のライブラリを特定する | ldd /path/to/binary | grep "not found" |
| 登録済みライブラリを検索する | ldconfig -p | grep ライブラリ名 |
| ライブラリキャッシュを更新する | ldconfig |
| 安全にライブラリ依存を確認する | readelf -d /path/to/binary | grep NEEDED |
| 静的リンクバイナリかどうか判別する | ldd /path/to/binary（not a dynamic executable と表示） |
| ディレクトリ配下を一括チェックする | find /usr/local/bin -type f -executable | xargs -I{} ldd {} 2>&1 | grep "not found" |
また、ライブラリが必要とするポートやプロセスを確認する場合は Linux ポート確認の全コマンド も合わせてご覧ください。
ldd で依存関係は調べられても、根本から身についていますか？
共有ライブラリの仕組みを知っていれば「not found」エラーで慌てなくなります。
ネットの断片情報をつなぎ合わせるだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：lsofコマンドで開いているファイルとポートを確認する方法｜プロセス特定と障害切り分けの実践例も
- この記事の属するカテゴリ：Linuxtips・Linuxコマンドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます