動的か静的かとは別に、ライブラリはプログラム間で共有される方式でも分類される。動的ライブラリは何らかの共有をサポートしており、複数のプログラムが同時に同じライブラリを使用することができる。静的ライブラリは各プログラムにリンクされるため、共有することはできない。 共有ライブラリ (shared library)は、やや曖昧な用語であり、ふたつの概念を含む。第一はディスク上のコードを複数の無関係なプログラムが共有することを意味する。第二の概念はメモリ上のコードの共有であり、ライブラリのロードされた物理メモリページが複数のプロセスのアドレス空間にマップされ、同時にアクセスされることを意味する。一般に後者を共有ライブラリと称するのが推奨され、この方式には様々な利点がある。例えばOPENSTEPでは、アプリケーションの多くは数百Kバイトで即座にロード可能であり、その機能の大部分はライブラリ上に実装されていて、共有可能であるためにOSが別のプログラム用にメモリにロードしたコードイメージがそのまま使用できる。しかし、マルチタスク環境で共有されるコードは特別な配慮が必要であり、そのために性能が若干低下する。 メモリ上の共有ライブラリはUNIXではPosition Independent Code（位置非依存コード）を使って実現される。これは柔軟なアーキテクチャだが複雑であり、Windowsなどでは使われていない。Windowsなどは、DLL毎にマップすべきアドレスを事前に決めておくなどしてメモリ上で共有可能にしている。WindowsのDLLはUNIXから見れば共有ライブラリではない。（訳注：UNIXでもライブラリのマップすべきアドレスを決めている場合がある。ただしそれは性能向上目的であり、基本的にはPIC化されている。） 最近のOSでは共有ライブラリは通常の実行ファイルと同じ形式になっている。これにはふたつの利点がある。第一はひとつのローダで両方をロードできる。それによってローダが若干複雑化するが、十分コストに見合う程度である。第二はシンボルテーブルさえあれば実行ファイルをDLLとして使うことができる点である。このようなファイル形式として、ELF (UNIX)と PE (Windows)がある。Windowsではさらに進んでいて、フォントなどのリソースも同じファイル形式になっている。OPENSTEPでもほとんど全てのシステムリソースが同じファイル形式になっている。 DLLという用語はWindowsやOS/2で主に使われる。UNIXでは「共有ライブラリ」が一般的である。 マルチスレッド環境下でライブラリを使用するにあたっては、上述とは別の共有問題が発生する。ライブラリルーチンがデータ領域としてスタックのみを使う場合は問題ないが、ライブラリ内のデータ領域を使う場合、そのデータ領域がスレッド毎に用意されていないことが多い。したがって、そのようなライブラリルーチンを使う場合、実行ファイル側で同時に複数のスレッドが同じライブラリルーチンを使わないように注意しなければならないことがある。 1980年代終盤にエステサロン された動的リンクは1990年代初期にはほとんどのオペレーティングシステムで使用可能となった。ほぼ同時期にオブジェクト指向プログラミング (OOP)が市場に出回り始めた。OOP は従来のライブラリが提供していなかった情報を必要とした。それは、あるオブジェクトが依存しているオブジェクトのリストである。これはOOPの継承という機能の副作用であり、あるメソッドの完全な定義は複数の場所に分散して配置される可能性がある。これは単純化すればライブラリ間の依存関係ということになるが、真のOOPシステムではコンパイル時には依存関係が明らかでなく、そのために様々な解決方法が登場した。 同じころ、多層構造のシステムの考え方も出てきた。デスクトップコンピュータ上の表示プログラムが汎用コンピュータやミニコンピュータの記憶装置や演算機能を利用するものである。例えばGUIベースのレーシック がミニコンピュータにメッセージを送り、表示すべき膨大なデータの一部を得るというものが考えられた。RPCは既に使われていたが、それは標準化されていなかった。 主要なミニコンおよび汎用機メーカーがこれら二つの問題に関してプロジェクトを結成し、どこでも使えるOOPライブラリ形式を開発した。このようなシステムをオブジェクト・ライブラリ (object library)と呼んだり、リモートアクセスが可能ならば分散オブジェクト (distributed objects)と呼ぶ。マイクロソフト社のCOMは分散機能のないオブジェクトライブラリであり、DCOMはリモートアクセスを可能としたバージョンである。 一時期、オブジェクトライブラリはプログラミングの世界の「次の大きな出来事」とされた。様々なシステムが開発され、競争も激化した。例をあげると、IBMのSOM/DSOM、サン・マイクロシステムズのDOE、NeXTのPDO、DECの ObjectBroker、美容整形 のComponent Object Model (COM/DCOM)、そして様々なCORBAベースのシステムがある。 結局、OOPライブラリは次の大きな出来事ではなかった。マイクロソフトのCOMとNeXT（現在はアップル）のPDO以外は、ほとんど使われることも無くなったのである。 Javaではオブジェクトライブラリとして主にjarが使われている。その中には（圧縮された）クラスのバイトコード形式が格納されていて、Java-VMや特殊なクラスローダがそれをロードする。 GNU/Linux、Solaris、BSDの派生OS：/lib、/usr/lib、/usr/local/lib などのフォルダに置かれる libfoo.a や libfoo.so といったファイルはダイナミックリンクライブラリである。ファイル名は常に lib で始まり、.a（静的ライブラリ）か .so（ダイナミックリンクライブラリ）で終わる。オプションとしてインターフェイス番号が付与される場合がある。例えば、libfoo.so.2 は libfoo ライブラリの二番目のメジャーなインターフェイス番号の付いたダイナミックリンクライブラリである。古いUNIXではマイナー番号も使っている場合がある (libfoo.so.1.2)が、最近のUNIXではメジャ視力回復 号しか使っていない。動的にロードされたライブラリは /usr/libexec などのディレクトリに置かれる。ライブラリのディレクトリにある .la ファイルは libtool アーカイブである。 Mac OS X：静的ライブラリの命名法はBSDを踏襲していて、.dylib の代わりに .so を使うことも出来る。しかし、多くの動的ライブラリは「バンドル」 (bundles)と呼ばれる特別な場所に置かれ、ライブラリに関連するファイルやメタデータもそこに置かれる。例えば、"My Neat Library" というライブラリは "My Neat Library.framework" というバンドルに実装される。 Microsoft Windows：*.LIB というファイルは静的ライブラリで、*.DLL というファイルはダイナミックリンクライブラリである。インターフェイスのリビジョンはファイル内に書きこまれるか、COMインターフェイスを使って抽象化される。また、.NET アセンブリについては、内部のマニフェストに記述される。