スポンサーリンク

Ubuntuで共有ライブラリの場所を確認する方法とトラブルシューティング

icicles
記事内に広告が含まれています。
スポンサーリンク

はじめに

Ubuntu を使いこなす上で、共有ライブラリの概念は避けて通れません。特に、プログラムのインストールやトラブルシューティングを行う際に、共有ライブラリの場所を特定する必要が出てくることがあります。

この記事では、Ubuntuで共有ライブラリの場所を確認する方法を、初心者の方にもわかりやすく解説します。具体的なコマンドの使い方から、共有ライブラリがシステムでどのように扱われているかまで、幅広くご紹介します。

この記事を読むことで、以下のことができるようになります。

  • 共有ライブラリとは何か、その役割を理解する
  • Ubuntuで共有ライブラリの場所を調べるための様々な方法を習得する
  • 共有ライブラリに関するトラブルシューティングの基本的な知識を得る

ぜひ最後まで読んで、Ubuntuでの開発や運用をよりスムーズに進めてください。

共有ライブラリとは何か

共有ライブラリ とは、複数のプログラムで共通して利用できる、汎用的なプログラム部品の集まりです。まるで、レゴブロックのように、様々なプログラムを組み立てる際に、何度も繰り返し使える部品のような役割を果たします。

共有ライブラリの重要性

共有ライブラリが重要な理由は、以下の点が挙げられます。

  • コードの再利用性向上

同じ機能を持つコードを各プログラム内に重複して記述する必要がないため、開発効率が向上し、保守も容易になります。

  • ディスク容量の節約

共通の機能をライブラリとしてまとめることで、ディスク容量を節約できます。

  • プログラムのモジュール化

プログラムを小さな部品に分割し、再利用性を高めることができます。

  • プラットフォーム間の互換性

再コンパイルは必要ですが、異なるOSやCPUアーキテクチャで利用できるようにコンパイルすることができます。

  • コミュニティによる開発

世界中の開発者が作成したオープンソースのライブラリを自由に利用することができます。

つまり、共有ライブラリは、ソフトウェア開発の生産性、保守性、そして品質を向上させる上で不可欠な要素なのです。

具体的な例として、 GUIライブラリ、画像処理ライブラリ、数値計算ライブラリなどが挙げられます。これらのライブラリを利用することで、開発者は、低レベルな処理を意識することなく、より高次のレベルでプログラミングに集中することができます。

まとめると、共有ライブラリは、ソフトウェア開発において、コードの再利用性、効率性、そして柔軟性を高めるための強力なツールです。

Ubuntuにおけるライブラリの管理

主に以下の方法があります。

  • apt: Ubuntuの標準パッケージマネージャー。インストール、更新、削除を簡単に行えます。
  • サードパーティのリポジトリ: 公式リポジトリにないライブラリをインストールできますが、セキュリティリスクも伴います。
  • Flatpak, Snap: アプリケーションを隔離して実行できるパッケージ管理システムです。
  • ソースコードからのビルド: 最新版やカスタマイズしたライブラリを利用できますが、ビルド環境の構築が必要です。
スポンサーリンク

共有ライブラリの場所を確認するための基本コマンド

Ubuntuで共有ライブラリの場所を確認する際に、主に以下のコマンドが利用されます。

  • ldconfig コマンド
  • ldd コマンド

それぞれのコマンドの用途と使い方について説明します。

ldconfigコマンドでリンクと検索キャッシュを作成

ldconfigコマンドは、Linuxシステムに於いて共有ライブラリのリンクと検索キャッシュの作成を行うためのコマンドです。

共有ライブラリのリンクの作成

/etc/ld.so.conf に指定されたディレクトリにある共有ライブラリに対して、シンボリックリンクを作成します。これにより、プログラムが共有ライブラリを容易に探し出すことができるようになります。

Ubuntu の場合には、/etc/ld.so.conf.d/ ディレクトリ以下のファイルを include するように /etc/ld.so.conf に記載されています。/etc/ld.so.conf.d/以下のファイルで共有ライブラリが存在するディレクトリを指定しています。

$ ls -ld /etc/ld.*
-rw-r--r-- 1 root root 66955 Jan 18 10:01 /etc/ld.so.cache
-rw-r--r-- 1 root root    34 Dec 16  2020 /etc/ld.so.conf
drwxr-xr-x 2 root root  4096 Jun  4  2024 /etc/ld.so.conf.d

$ ls -l /etc/ld.so.conf.d/
total 36
-rw-r--r-- 1 root root  41 Apr  4  2023 000_cuda.conf
-rw-r--r-- 1 root root  44 Apr  4  2023 988_cuda-12.conf
-rw-r--r-- 1 root root  44 Sep 22  2022 989_cuda-11.conf
-rw-r--r-- 1 root root  38 Mar  6  2022 fakeroot-x86_64-linux-gnu.conf
-rw-r--r-- 1 root root  46 Jun 23  2022 gds-11-8.conf
-rw-r--r-- 1 root root  46 Apr  5  2023 gds-12-1.conf
-rw-r--r-- 1 root root 182 Jan 18 10:00 ld.wsl.conf
-rw-r--r-- 1 root root  44 Dec 16  2020 libc.conf
-rw-r--r-- 1 root root 100 Mar  4  2022 x86_64-linux-gnu.conf

$ cat /etc/ld.so.conf.d/000_cuda.conf
/usr/local/cuda/targets/x86_64-linux/lib

nVidia CUDA の共有ライブラリは /usr/local/cuda/targets/x86_64-linux/lib ディレクトリ以下にある事が分かります。これらのディレクトリを対象に、ldconfig コマンドはシンボリックリンクを作成します。

$ cd /usr/local/cuda/targets/x86_64-linux/lib/
$ ls -l libcuda*
-rw-r--r-- 1 root root 1653306 Apr  4  2023 libcudadevrt.a
lrwxrwxrwx 1 root root      15 Apr  4  2023 libcudart.so -> libcudart.so.12
lrwxrwxrwx 1 root root      21 Apr  4  2023 libcudart.so.12 -> libcudart.so.12.1.105
-rw-r--r-- 1 root root  679264 Apr  4  2023 libcudart.so.12.1.105
-rw-r--r-- 1 root root 1176672 Apr  4  2023 libcudart_static.a

libcudart.so.12.1.105 がライブラリ本体で、libcudart.so.12 と libcudart.so がシンボリックリンクになります。

共有ライブラリの検索キャッシュの作成

作成されたシンボリックリンクの情報に基づいて、共有ライブラリの検索キャッシュファイル(/etc/ld.so.cache) を更新します。このキャッシュファイルは、プログラム実行時に共有ライブラリを探す際に参照されます。

$ ls -l /etc/ld.so.cache
-rw-r--r-- 1 root root 66955 Jan 18 10:01 /etc/ld.so.cache

実行例

Ubuntu では ldconfig コマンドは /usr/sbin ディレクトリに存在します。ldconfig コマンドを実行する為には root (スーパーユーザー) の権限が必要です。

$ ls -l /etc/ld.so.cache
-rw-r--r-- 1 root root 66955 Jan 18 10:01 /etc/ld.so.cache

$ sudo ldconfig
[sudo] password for hiro:

$ ls -l /etc/ld.so.cache
-rw-r--r-- 1 root root 66955 Jan 18 10:28 /etc/ld.so.cache

何も表示されませんが (エラーがあればメッセージが表示されます)、共有ライブラリのシンボリックリンクと検索キャッシュの作成が行われています。検索キャッシュファイルの更新日時が変わっていますので、実際に作成されている事が分かります。

また、ldconfig コマンドは現在の検索内容のキャッシュを表示する事が出来ます。こちらは一般ユーザーでも実行可能です。キャッシュ表示のオプションは "-p" です。

$ ldconfig -p | grep cudart
        libcudart.so.12 (libc6,x86-64) => /usr/local/cuda/targets/x86_64-linux/lib/libcudart.so.12
        libcudart.so (libc6,x86-64) => /usr/local/cuda/targets/x86_64-linux/lib/libcudart.so

$ ldconfig -p | head -n 1
997 libs found in cache `/etc/ld.so.cache'

私の環境では、997 個の共有ライブラリがインストールされていました。

ldconfigコマンドは、共有ライブラリを効率的に管理するために不可欠なコマンドです。新しいライブラリをインストールしたり、/etc/ld.so.confファイルを編集した後は、必ずldconfigコマンドを実行してキャッシュを更新するようにしましょう。

lddコマンドで依存関係を確認

lddコマンドは、実行ファイルや共有オブジェクトが、実行時にどの共有ライブラリに依存しているかを調べるためのコマンドです。

指定したファイルが動作するために必要な他のライブラリを一覧表示します。bash と ls を例に実行してみます。

$ ldd /usr/bin/bash
        linux-vdso.so.1 (0x00007fffdf79d000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007efc9a744000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efc9a51b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007efc9a8ea000)
$ ldd /usr/bin/ls
        linux-vdso.so.1 (0x00007ffdf24aa000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f58725d0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f58723a7000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f5872310000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5872633000)

/usr/bin/bash ファイルは4つ、/usr/bin/ls は5つの共有ライブラリを使用している事が分かります。

共有ライブラリが見つからない場合には、後半部分に "not found" と表示されます。

lddコマンドは、プログラムの依存関係を調べる上で非常に便利なツールです。プログラムのトラブルシューティングや、ライブラリの管理に活用することができます。

環境変数LD_LIBRARY_PATHの設定

共有ライブラリを探す場所を指定するには、ldconfig コマンドで検索キャッシュファイルの /etc/ld.so.cache を作成する他に、もう一つの方法があります。それは環境変数として LD_LIBRARY_PATH を設定する方法です。

LD_LIBRARY_PATHとは

LD_LIBRARY_PATHは、プログラム実行時に、共有ライブラリを探すためのディレクトリパスを指定する環境変数です。この変数に指定されたディレクトリは、システムで標準的に設定されているライブラリ検索パスよりも優先的に検索されます。

なぜLD_LIBRARY_PATHを設定する必要があるのでしょうか。それには理由が二つあります。

  • 非標準の場所にインストールされたライブラリを使用する場合

システム標準のライブラリディレクトリ以外にインストールされたライブラリを使用したい場合、LD_LIBRARY_PATHにそのディレクトリを指定することで、プログラムがそのライブラリを見つけられるようにします。

  • 複数のバージョンのライブラリを共存させる場合

異なるバージョンのライブラリをインストールし、プログラムごとに使用するバージョンを切り替えたい場合に、LD_LIBRARY_PATHを調整することで、実行時に使用するライブラリを指定できます。

システム標準のライブラリ検索パスよりも優先的に検索される事を利用して、このような使い方が可能となっています。

環境変数の設定手順

bash のプロンプト、あるいはシェルスクリプトの中で export コマンドで設定します。

$ export LD_LIBRARY_PATH=/path/to/your/library:$LD_LIBRARY_PATH
  • exportコマンドで環境変数を設定します。
  • /path/to/your/libraryの部分には、ライブラリが置かれているディレクトリのパスを指定します。
  • $LD_LIBRARY_PATHの部分は、既存のLD_LIBRARY_PATHの値に追加するためです。

bash 起動時に自動で設定させたい場合には、~/.bashrc や ~/.profile に追記します。

環境変数LD_LIBRARY_PATH使用時の注意点

環境変数LD_LIBRARY_PATHを設定して共有ライブラリを読み込むのは便利な機能ですが、次のようなリスクがありますのでご注意下さい。

  • セキュリティリスク

任意のディレクトリを指定できるため、悪意のあるライブラリが読み込まれる可能性があります。信頼できるソースから取得したライブラリのみを使用するようにしましょう。

  • 依存関係

ライブラリ間の依存関係が複雑な場合、LD_LIBRARY_PATHの設定ミスにより、プログラムが正常に動作しなくなることがあります。

  • 一時的な設定

シェルを終了すると、LD_LIBRARY_PATHの設定はリセットされます。永続的に設定したい場合は、シェルの設定ファイルに記述するか、システム全体のライブラリ検索パスを変更する必要があります。

LD_LIBRARY_PATHは、プログラムが使用する共有ライブラリの検索パスを柔軟に設定するための環境変数です。しかし、誤った設定は、セキュリティリスクやプログラムの動作不良を引き起こす可能性があるため、慎重に扱う必要があります。

エラーメッセージの解決方法

共有ライブラリを使用する際に生じるエラーについて、主なエラーメッセージについて原因と対処方法について説明します。

Cannot open shared object fileエラー

"Cannot open shared object file" というエラーは、プログラム実行時に必要な共有ライブラリが見つからない、または読み込めない際に発生します。具体的には以下のようなメッセージが表示されます。

libc.so.6: cannot open shared object file: No such file or directory
libmysqlclient.so.20: cannot open shared object file: Cannot allocate memory

このエラーは、様々な原因が考えられます。

  • 共有ライブラリが存在しない (No such file or directory)
    • ライブラリがインストールされていない
    • ライブラリのパスが間違っている
    • ライブラリが削除された
  • ライブラリのバージョンが合わない
    • プログラムが要求するライブラリのバージョンと、インストールされているライブラリのバージョンが異なる
  • ライブラリの依存関係が満たされていない
    • 目的のライブラリが他のライブラリに依存している場合、依存関係が満たされていない
  • ファイルのパーミッション問題
    • ライブラリファイルに対する読み込み権限がない
  • その他
    • メモリ不足
    • ライブラリファイルの破損
    • ライブラリの競合

No such file or directory エラーの対処

このエラーは共有ライブラリが見つからない場合や、共有ライブラリのバージョンが異なる場合に発生します。

  • /etc/ld.so.conf や LD_LIBRARY_PATH の設定の見直し
  • 正しいバージョンのライブラリをインストール

パッケージマネージャーのバージョン指定オプションを利用して、必要なバージョンのライブラリをインストールします。

  • プログラムを再コンパイル

プログラムを再コンパイルし、インストールされているライブラリに合わせるようにします。

まとめ

Ubuntu の標準的な apt line のみを使用している場合には、共有ライブラリのトラブルが発生する事は稀です。これまで、私はそのようなトラブルが発生した事はありません。Ubuntu のパッケージ管理を担当されている方々には非常に感謝しています。

対して、

  • 非標準の apt line を追加した場合
  • deb パッケージを直接インストールした場合
  • 自分でプログラムをコンパイルした場合

などに、共有ライブラリ回りのトラブルは幾度も経験しています。最近でも、WSL2 で CUDA を使用する場合に、本来シンボリックでなければならないライブラリが実体ファイルに変わってしまう事に起因するトラブルを経験しました。

初期の Linux では全てスタティックリンク (全てのライブラリを実行ファイルに含める) でした。今でもインストーラ等はそのような形です。

共有ライブラリを使用する事で、各実行ファイルの容量やメモリ量が少なくなり、共通部品として共用するメリットが生まれます。共有ライブラリを上手く利用する事は、Ubuntu を使用する上で、覚えておくと良い内容だと思います。

[

Amazon の Mac mini A4 の低価格品の在庫が復活していました。Amazon ポイント貯めて購入する予定です。初 Mac、楽しみです。

コメント

  1. […] Ubuntuで共有ライブラリの場所を確認する方法とトラブルシューティング | hiroの長い長い冒険日記Ubuntu で共有ライブラリの場所を確認する方法と、発生しやすいトラブルの原因と対策に […]

タイトルとURLをコピーしました