バイナリ自体は、依存する共有ライブラリのバージョンを認識しており、具体的に要求します。 ldd を使用できます 依存関係を表示します。 ls の鉱山
$ ldd /bin/ls
linux-gate.so.1 => (0xb784e000)
librt.so.1 => /lib/librt.so.1 (0xb782c000)
libacl.so.1 => /lib/libacl.so.1 (0xb7824000)
libc.so.6 => /lib/libc.so.6 (0xb76dc000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb76c3000)
/lib/ld-linux.so.2 (0xb784f000)
libattr.so.1 => /lib/libattr.so.1 (0xb76bd000)
ご覧のとおり、たとえば次を指しています。 libpthread.so.0 、 libpthread.so だけではありません .
シンボリック リンクの理由は、リンカのためです。 libpthread.so にリンクしたい場合 直接、あなたは gcc を与えます フラグ -lpthread 、そして lib に追加します プレフィックスと .so 接尾辞を自動的に付けます。 .so.0 に追加するように指示することはできません そのため、シンボリック リンクは lib の最新バージョンを指し示し、それを容易にします
共有ライブラリの番号は、ライブラリの API を識別するために Linux で使用される規則です。通常、フォーマットは次のとおりです:
libFOO.so.MAJOR.MINOR
お気づきのように、通常、libFOO.so から libFOO.so.MAJOR.MINOR へのシンボリック リンクがあります。 ldconfig は、このリンクを最新バージョンに更新する責任があります。
MAJOR は通常、API が変更された場合 (新しいエントリ ポイントが削除された場合、またはパラメーターまたは型が変更された場合) にインクリメントされます。 MINOR は通常、バグ修正リリースの場合、または既存の API を壊さずに新しい API が導入された場合に増分されます。
より広範な議論はここにあります:共有ライブラリの分析
共有ライブラリは、次のスキームに従ってバージョン管理する必要があります:
blah.so.X.Y.Z
どこで
- X =下位互換性のない ABI リリース
- Y =下位互換性のある ABI リリース
- Z =内部変更のみ - ABI への変更なし
通常、hello.so.1 のような最初の数字のみが表示されます 他のすべての数字は下位互換性があるため、ライブラリの「バージョン」を識別するために必要なのは最初の数字だけだからです。
ldconfig システムで利用可能な共有ライブラリと、そのライブラリへのパスが存在する場所のテーブルを維持します。これを確認するには、次を実行します:
ldconfig -p
Red Hat などのパッケージがビルドされると、バイナリで呼び出される共有ライブラリが検索され、RPM ビルド時にパッケージの依存関係として追加されます。したがって、パッケージをインストールしようとすると、インストーラーは hello.so.1 かどうかを調べます。 ldconfig をチェックすることでシステムにインストールされます .
次のような方法でパッケージの依存関係を確認できます:
rpm -qpR hello.rpm
このシステムは (Windows とは異なり) hello.so の複数のバージョンを許可します。 システムにインストールされ、異なるアプリケーションで同時に使用されます。