☰

複数のバージョンの共有ライブラリをインストールできないのはなぜですか？

tag-icon • tag-icon package-management dynamic-linking version shared-library
複数のバージョンの共有ライブラリをインストールできないのはなぜですか？

一般に、あるプログラムはライブラリのバージョンxyに依存し、他のプログラムはxzに依存しますが、私が知っている限り、パッケージマネージャはxyとxzの両方をインストールすることはできません。可能ですが、マイナーバージョンはまったくないようです。

なぜこれですか？たとえば、これを防ぐための制限要因は何ですか？このように役に立つような機能を許可しないのにはそれほどの理由があると思います。たとえば、共有オブジェクトをロードするときにロードするバージョンを示すフィールドがないため、Linuxがロードするバージョンを決定する方法がわかりませんか？それとも本当に理由がないのでしょうか？すべてのマイナーバージョンが互換性があるように見えますか？

ベストアンサー1

実際に正しく実行されたら、複数のバージョンの共有ライブラリをインストールできます。

共有ライブラリの名前は通常次のとおりです。

lib<name>.so.<api-version>.<minor>

次に、次のライブラリへのシンボリックリンクがあります。

lib<name>.so
lib<name>.so.<api-version>

開発者がバイナリを生成するためにライブラリに接続すると、.soリンカはそのファイル名で終わるファイル名を探します。特定の状況で一度に1つしかインストールできないことは事実ですが、<name>これは開発者が同時に複数のバージョンのライブラリをターゲットにすることはできません。パッケージ管理者にとって、このシンボリックリンクは開発者だけがインストールする必要がある.so別のパッケージの一部です。-dev

リンカは、名前が終わるファイルを見つけて使用する.soと、そのライブラリ内の次のフィールドを探します。ソナム。 sonameは、生成されたバイナリに含めるファイル名と、実行時に見つける必要があるファイル名をリンカに提案します。 sonameをに設定する必要がありますlib<name>.so.<api-version>。

したがって、実行時に動的リンカーはそれを見つけてlib<name>.so.<api-version>使用します。

意図は次のとおりです。

  • <minor>アップグレードはライブラリのAPIを変更せず、ライブラリが親バージョンに<minor>アップグレードされると、すべてのバイナリを新しいバージョンに安全にアップグレードできます。バイナリはすべて、lib<name>.so.<api-version>最新のインストールへのシンボリックリンクである名前でライブラリを探しているので、lib<name>.so.<api-version>.<minor>アップグレードを実行します。
  • <api-version>アップグレードすると、ライブラリのAPIが変更され、既存のバイナリアプリケーションが新しいバージョンを使用するのが安全になりません。変更された場合、<api-version>これらのアプリケーションは名前を探していますが、lib<name>.so.<api-version>値が異なるため、<api-version>新しいバージョンは選択されません。

パッケージマネージャは通常、同じリリースに同じライブラリの複数のバージョンをパッケージ化しません。ディストリビューション全体（ライブラリを使用するすべてのバイナリを含む）は、通常、リリース前に各ライブラリの一貫したバージョンを使用するようにコンパイルされるためです。解放されました。すべてが一貫しており、リリース内のすべてが他のすべてと互換性があることを確認することは、出版社のワークロードの大部分を占めます。

ただし、ディストリビューションのあるバージョンから別のバージョンにシステムをアップグレードしても、以前のバージョンのライブラリが必要な古いパッケージがいくつかある場合は、複数のバージョンのライブラリが簡単に発生する可能性があります。例:

おすすめ記事