ライブラリをリリースするたびに、おそらくバージョン番号が異なるはずです。ただし、一部のリリースでは、バグを修正する以外にユーザーにまったく影響を与えることなく、ライブラリの内部動作に変更を加えるだけです。他のリリースでもライブラリに新しい関数が追加される場合がありますが、既存のすべての関数のインターフェイスの詳細は以前と同じであるため、古いバージョンのライブラリを使用するように作成されたソフトウェアは引き続き新しいバージョンで動作します。その他の変更により、下位互換性が損なわれる可能性があります。関数インターフェイスが変更されたり、構造がサイズを変更したり、関数が削除されたりします(または、グローバル変数-思考を失います-変更など)。
「バグ修正のみ」のバージョンは、ライブラリの番号の付け直しを気にしないかもしれませんが、以前に持っていた場合liberror.so.1.0.2
、新しいバージョンはliberror.so.1.0.3
、リリース番号の変更である可能性があります。
「追加機能」バージョンには新しいマイナー番号を付ける必要があるため、後の新しいバージョンは。にliberror.so.1.0.2
なる可能性がありますliberror.so.1.1.0
。
互換性が失われた場合は、新しいバージョン番号を使用するため、後の新しいバージョンは。にliberror.so.1.0.2
なる可能性がありますliberror.so.2.0.0
。
使用するように構築されたコードは、問題なく、または問題なくliberror.so.1.0.2
使用できますが、それ以降のバージョンを使用しようとはしません。liberror.so.1.0.3
liberror-1.1.0
liberror.so.2.0.0
どのコード(たとえば、GNU binutilsスタック内)がリンクされるバージョンを制御し、この動作は修正またはオーバーライド可能ですか?
良い質問。 これは私の理解ですが、詳細が間違っている可能性があります(その場合、誰かが私のやり方の誤りを指摘する可能性があります)。上記の理論は簡単です。これは少し簡単ではありません。
ライブラリの「開発」パッケージと「標準」バージョンのライブラリがあることに気付いたかもしれません。それらの違いは説明の一部です。
ライブラリを使用してプログラムを作成するのではなく、他の誰かが作成したプログラムを実行するだけの通常のエンドユーザーの場合、通常、インストールディレクトリに1つのファイルと1つのシンボリックリンクがあります。架空のliberror.so.1.0.2
例(にインストールされている/usr/local/lib
)を続けると、ベースリリースに次のように表示されます。
liberror.so.1.0.2 — the real shared object
liberror.so.1 — symlink to the the real shared object
開発バージョンをインストールした場合、おそらくいくつかのヘッダーファイル/usr/local/include
、いくつかのマニュアルページ(おそらく/usr/local/man
、/usr/share
代わりに)、および追加のシンボリックリンクがあります。
liberror.so — another symlink, either to liberror.so.1 or to liberror.so.1.0.2
それを使用するプログラムがコンパイルされるとき、あなたは以下を指定するかもしれません:
gcc -I/usr/local/include usererror.c -o usererror -L/usr/local/lib -lerror
これは名前とリンクしますliberror.so
が、ファイルからメタデータを読み取ると、liberror.so.1.0.2
使用するバージョンがそれ以降であることがわかりますliberror.so.1.0.2
(ただし、liberror.so.2.0.0
それ以降ではありません)。
ここで、インストールをにアップグレードするとしますliberror.so.2.0.0
。これでファイルができました:
liberror.so.1.0.2 — the real shared object
liberror.so.1 — symlink to the the real shared object
liberror.so.2.0.0 — the real shared object
liberror.so.2 — symlink to the the real shared object
liberror.so — another symlink, either to liberror.so.2 or to liberror.so.2.0.0
使用するために構築された古いコードは、liberror.so.1
引き続きそのライブラリを使用して実行されます。使用するために構築された新しいコードliberror.so.2
も、新しいライブラリを使用して実行されます。liberror.so.2.0.0
そしてリンク時に、新しいプログラムはシンボリックリンクを介してピックアップしliberror.so
ます。
を指すようにシンボリックリンクをliberror.so.1
調整することにより、システムのデフォルトが維持されるように制御できます。唯一注意が必要なのは、正しいバージョンのヘッダーをコンパイルできるようにすることです。のヘッダーを使用してビルドし、リンクすることはお勧めできません。確かに知っていることの1つは、インターフェイスが異なることです。liberror.so
liberror.so.1.0.2
liberror.so.2
liberror.so.1
Red Hat Enterprise Linux 5(RHEL5)x86_64マシンからの一部の生データ。
$ cd /lib64
$ ls libc*
-rwxr-xr-x 1 root root 1713088 2009-01-05 16:32 libc-2.5.so
lrwxrwxrwx 1 root root 11 2012-02-22 15:05 libcap.so -> libcap.so.1
lrwxrwxrwx 1 root root 14 2012-02-22 15:05 libcap.so.1 -> libcap.so.1.10
-rwxr-xr-x 1 root root 17384 2006-11-14 01:36 libcap.so.1.10
-rwxr-xr-x 1 root root 197744 2009-01-05 16:32 libcidn-2.5.so
lrwxrwxrwx 1 root root 14 2012-02-22 15:05 libcidn.so.1 -> libcidn-2.5.so
lrwxrwxrwx 1 root root 17 2012-02-22 15:05 libcom_err.so.2 -> libcom_err.so.2.1
-rwxr-xr-x 1 root root 10000 2008-09-30 13:27 libcom_err.so.2.1
-rwxr-xr-x 1 root root 48600 2009-01-05 16:32 libcrypt-2.5.so
-rwxr-xr-x 1 root root 1048728 2005-10-31 06:47 libcrypto.so.0.9.6b
-rwxr-xr-x 1 root root 1365504 2008-12-16 08:09 libcrypto.so.0.9.8e
lrwxrwxrwx 1 root root 19 2012-02-22 15:05 libcrypto.so.2 -> libcrypto.so.0.9.6b
lrwxrwxrwx 1 root root 19 2012-02-22 15:05 libcrypto.so.4 -> libcrypto.so.0.9.8e
lrwxrwxrwx 1 root root 19 2012-02-22 15:05 libcrypto.so.6 -> libcrypto.so.0.9.8e
lrwxrwxrwx 1 root root 15 2012-02-22 15:05 libcrypt.so.1 -> libcrypt-2.5.so
lrwxrwxrwx 1 root root 11 2012-02-22 15:05 libc.so.6 -> libc-2.5.so
$
libc.so.6
はへのシンボリックリンクであることがわかりますlibc-2.5.so
。libcrypto
リンク時ライブラリを含まない、の多くのバージョンを使用することもできますlibcrypto.so
。また、バージョン番号などの2つの部分しかないライブラリも表示されます。表されるライブラリlibc
は、、、、、、およびlibcap
です。libcidn
libcom_err
libcrypt
libcrypto