共有ライブラリマイナーバージョン管理

次の簡単なプログラムがありますmain。

#include <iostream>
#include "random.h"

int main()
{
        std::cout << "The program has started\n";
        return get_another_random_number();
}

このget_another_random_number()機能は新しいバージョンの共有ライブラリにありますが、以前のバージョンのみがインストールされています。たとえば、プログラムの実行が開始されますが、後で照会が失敗すると、競合が発生します。

$ ./main
The program has started
./main: symbol lookup error: ./main: undefined symbol: _Z25get_another_random_numberv

---

たとえば、librandom.so.1.3.1という関数が含まれているがインストールしたばかりのget_another_random_number()サーバーmainでこの関数を実行した場合、これが発生しますlibrandom.so.1.2.5。ライブラリはマイナーバージョンでのみ異なります。これは1.3ライブラリのバージョンと以前のバージョンと互換性がありますが、追加機能が不足しているためです。1.21.2

私の例で実行すると、次のような結果がreadelf -d main | grep NEEDED得られます。

 0x0000000000000001 (NEEDED)             Shared library: [librandom.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

したがって、すべてはメジャーバージョン番号にのみ関連付けられます。

私の共有ライブラリにこれを置き、/usr/lib/シンボリックリンクを追加しました。

lrwxrwxrwx 1 root root     23 Feb  7 14:25 /usr/lib/librandom.so -> /usr/lib/librandom.so.1
lrwxrwxrwx 1 root root     27 Feb  7 14:13 /usr/lib/librandom.so.1 -> /usr/lib/librandom.so.1.2.5
-rw-r--r-- 1 root root   7696 Feb  7 14:00 /usr/lib/librandom.so.1.2.5

ライブラリ管理者、アプリケーション開発者、システム管理者のうち、このプログラムがクラッシュしないようにする責任は誰にありますか？

• インストールプロセスでmain現在インストールされているライブラリのマイナーバージョンが低すぎるというエラーが発生しますか？
• プログラムがバージョンを識別し、マイナーバージョンが十分であることを確認するために、ライブラリの特殊関数を呼び出す必要がありますか？
• プログラムの実行を開始する前に、ライブラリローダはすべてのシンボルを確認する必要がありますか？
• バージョン番号を誤って理解したか、マイナーバージョンを確認する設定を見逃したのでしょうか？