共有ライブラリとは、実行可能コードのライブラリであり、メモリにロードされて、複数の実行可能ファイル(プログラムや他のライブラリ)が実行時に使用できるようになっているものです。[ 1 ] [ 2 ] [ 3 ]
対照的に、静的ライブラリは実行可能ファイルにコピーされます。静的ライブラリは複数の実行可能ファイルで再利用(共有の一形態)できますが、各実行可能ファイルにはライブラリコードのコピーが含まれており、他の実行可能ファイルとメモリ内でコピーを共有しません。今日では当てはまりませんが、歴史的にはすべてのライブラリは静的でした。[ 4 ]共有ライブラリは静的リンクを持つことができますが、そのようなライブラリは静的ライブラリとは分類されません。
共有ライブラリは、多くの場合、動的リンカーによってロードされる動的ライブラリでもあります。そのため、静的リンクの場合よりもプログラマにとってライブラリの利用が容易になります。動的ライブラリは複数の実行ファイルからアクセス可能である必要はなく(共有ライブラリ)、また、共有ライブラリはコンシューマー実行時にロードされる必要もありません(動的ライブラリ)。
ライブラリコードは、複数のプロセス間でメモリ上およびディスク上で共有される場合があります。仮想メモリを使用する場合、プロセスは、それぞれの異なるアドレス空間にマッピングされた同じ物理RAMページを実行します。これには利点があります。例えば、OpenStepシステムでは、アプリケーションのサイズは数百キロバイト程度で、高速にロードされました。そのコードの大部分は、オペレーティングシステムによって他の目的で既にロードされているライブラリに格納されていました。
プログラムは、 Unixのように位置独立コードを使用することで RAM の共有を実現できます。Unixでは、複雑ながら柔軟なアーキテクチャが実現されます。また、Windows やOS/2のように、共通の仮想アドレスを使用する方法もあります。これらのシステムでは、アドレス空間を事前にマッピングしたり、共有ライブラリごとにスロットを予約したりするなど、さまざまな方法でコードが共有される可能性が高くなります。3 つ目の選択肢は、IBM System/38とその後継システムで使用されている、単一のアドレス空間を持つ単一レベルのストアです。これにより、位置依存コードが使用可能になり、プログラムとライブラリにはそのアドレス空間内の永続的なアドレスが割り当てられます。
場合によっては、共有ライブラリの異なるバージョンが問題を引き起こすことがあります。特に、異なるバージョンのライブラリが同じファイル名を持ち、それぞれ特定のバージョンを必要とするさまざまなアプリケーションがシステムにインストールされている場合に問題となります。この状況は、Windows および OS/2 のDLL ファイルにちなんでDLL 地獄と呼ばれています。2001 年以降のほとんどの最新のオペレーティングシステムには、このような状況を解消するためのクリーンアップ方法、またはアプリケーション固有の「プライベート」ライブラリを使用する方法があります。[ 5 ]
以下の一般的に使用されているライブラリ技術は、いずれも共有型かつ動的な性質を持つ。
特定のアプリケーションとともにインストールされ、そのアプリケーションのみで使用される DLL です。