
コンピューティングにおいて、ライブラリとは、ソフトウェア開発中にコンピュータプログラムを実装するために使用できるリソースの集合体です。一般的に、ライブラリはコンパイルされた関数やクラスなどの実行可能コードで構成されますが、ソースコードの集合体である場合もあります。リソースライブラリには、画像やテキストなどのデータが含まれる場合があります。
ライブラリは、複数の独立した利用者(プログラムや他のライブラリ)から利用できます。これは、プログラム内で定義されたリソース(通常はそのプログラムでのみ使用可能)とは異なります。利用者がライブラリリソースを使用すると、ライブラリ自体を実装することなく、そのライブラリの価値を得ることができます。ライブラリは、モジュール形式でのソフトウェアの再利用を促進します。ライブラリは他のライブラリも使用できるため、プログラム内にライブラリの階層構造が形成されます。
ライブラリを使用するコードを書く場合、プログラマーはライブラリの内部構造を理解する必要はなく、そのライブラリのアプリケーション・プログラミング・インターフェース(API)の使い方さえ知っていれば十分です。例えば、複雑なシステムコールを抽象化するライブラリを使用することで、プログラマーはシステム関数の複雑な仕組みを学習することなく、システム機能を利用できるようになります。
コンピュータライブラリのアイデアは、チャールズ・バベッジが初めてコンピュータを開発した頃に遡ります。1888年に発表された解析機関に関する論文では、コンピュータの演算処理を数値入力とは別のカードにパンチできることが示唆されていました。これらの演算処理用のパンチカードを再利用のために保存しておけば、「次第に解析機関は独自のライブラリを持つようになるだろう」とされています。[ 1 ]

1947年、ゴールドスタインとフォン・ノイマンは、当時まだ稼働していなかった初期のコンピュータであるIASマシンでの作業にサブルーチンの「ライブラリ」を作成することが有用であると推測しました。 [ 2 ]彼らは、磁気ワイヤ記録の物理的なライブラリを構想し、各ワイヤに再利用可能なコンピュータコードを格納しました。[ 3 ]
フォン・ノイマンに触発され、ウィルクスと彼のチームはEDSACを構築した。パンチテープを収納したファイルキャビネットに、このコンピュータのサブルーチンライブラリが収められていた。[ 4 ] EDSACのプログラムは、メインプログラムと、サブルーチンライブラリからコピーされた一連のサブルーチンで構成されていた。[ 5 ] 1951年、チームはプログラミングに関する最初の教科書『The Preparation of Programs for an Electronic Digital Computer』を出版し、ライブラリの作成と目的を詳細に説明した。[ 6 ]
1959年のCOBOLには「ライブラリシステムのための基本的な機能」が含まれていましたが[ 7 ] 、 Jean Sammetは後から振り返ってそれを「不十分なライブラリ機能」と評しました[ 8 ] 。
JOVIAL には、通信プール (COMPOOL) があり、これはヘッダー ファイルのライブラリとほぼ言えます。
現代のライブラリ概念へのもう一つの大きな貢献は、 FORTRANにおけるサブプログラムの革新でした。FORTRANのサブプログラムは互いに独立してコンパイルできますが、コンパイラにはリンカーがありませんでした。そのため、Fortran-90でモジュールが導入される前は、FORTRAN [注1 ]サブプログラム間の型チェックは不可能でした。[ 9 ]
1960年代半ばまでに、アセンブラ用のコピーライブラリとマクロライブラリは一般的になりました。IBM System/360の普及に伴い、システムパラメータなど、他の種類のテキスト要素を含むライブラリも普及しました。
IBM の OS/360 およびその後継製品では、これをパーティション データ セットと呼びます。
1965年に開発された最初のオブジェクト指向プログラミング言語であるSimulaは、コンパイラを介してライブラリにクラスを追加することをサポートしていました。 [ 10 ] [ 11 ]
リンク(またはバインディング)プロセスは、シンボル(またはリンク)と呼ばれる参照を、設定されたライブラリを含む様々な場所で検索することで解決します。リンカー(またはバインダー)がシンボルを見つけられない場合、処理は失敗しますが、複数のシンボルが一致した場合、処理が失敗することもあります。
静的リンクはビルド時にリンクを行い、ライブラリの実行可能コードをプログラムに組み込みます。動的リンクは実行時にリンクを行い、ダイナミックリンクライブラリ(DLL)への実行時リンクをサポートする情報を使用してプログラムをビルドします。動的リンクの場合、プログラムの実行時に互換性のあるDLLファイルが利用可能である必要がありますが、静的リンクの場合、プログラムはスタンドアロンです。
スマートリンクは、ビルドツールによって実行され、リンクプロセスにおいて未使用のコードを除外します。例えば、算術演算に整数のみを使用するプログラム、または算術演算を全く行わないプログラムでは、浮動小数点ライブラリルーチンを除外できます。これにより、プログラムファイルのサイズが小さくなり、メモリ使用量も削減されます。
プログラムまたはライブラリモジュール内の一部の参照は相対形式またはシンボリック形式で保存されており、すべてのコードとライブラリに最終的な静的アドレスが割り当てられるまで解決できません。再配置はこれらの参照を調整するプロセスであり、リンカーまたはローダーによって実行されます。一般に、個々のライブラリ自体に対して再配置を行うことはできません。これは、メモリ内のアドレスが、それらを使用するプログラムや、それらと組み合わせられる他のライブラリによって異なる可能性があるためです。位置非依存コードは絶対アドレスへの参照を回避するため、再配置は必要ありません。
実行可能ライブラリは、ソースコードから機械語またはバイトコードなどの中間形式に変換されたコードで構成されています。リンカーは、各参照をオブジェクトが配置されているアドレスに関連付けることで、ライブラリオブジェクトの使用を可能にします。例えば、C言語では、ライブラリ関数はC言語の通常の関数呼び出し構文とセマンティクスによって呼び出されます。[ 12 ]
バリアントとは、OS ではロードできないがリンカーでは読み取ることができる形式でコンパイルされたコード (IBM の命名法ではオブジェクト コード) を含むライブラリです。
静的ライブラリとは、リンカー(あるいはリンクを行うビルドツールの名称)によってビルド時にプログラムにリンクされる実行可能ライブラリである。[ 13 ] [ 14 ]このプロセスと、その結果生成されるスタンドアロンファイルは、プログラムの静的ビルドと呼ばれる。仮想メモリが使用され、アドレス空間レイアウトのランダム化が不要な場合、静的ビルドではそれ以上の再配置は不要となる場合がある。[ 15 ]
静的ライブラリは、Unix 系システムでは アーカイブと呼ばれることもあります。
動的ライブラリは、プログラムの実行時(ロード時または実行時)にリンクされます。動的ライブラリは、静的ライブラリの後に、ソフトウェアの展開における柔軟性を高めるために開発されました。
ソース ライブラリは、コンパイルされたコードではなく、ソース コードで構成されます。
共有ライブラリとは、実行時に複数のコンピュータプログラムや他のライブラリによって使用されるように設計された実行可能コードを含むライブラリであり、そのコードのコピーはメモリ内に1つだけ存在し、そのコードを使用するすべてのプログラムによって共有されます。[ 16 ] [ 17 ] [ 18 ]
現在では一般的には時代遅れの技術ですが、オブジェクトライブラリはオブジェクト指向プログラミング(OOP)用のリソースを公開し、分散オブジェクトはリモートオブジェクトライブラリです。例としては、COM /DCOM、SOM /DSOM、DOE、PDO、そして様々なCORBAベースのシステムなどが挙げられます。
オブジェクトライブラリ技術は、OOPが普及するにつれて、OOPランタイムバインディングには当時のライブラリが提供していない情報が必要であることが明らかになったため開発されました。OOPバインディングでは、内部にあるコードの名前とエントリポイントに加えて、継承のため、メソッドの完全な定義が異なる場所にある可能性があるため、依存関係のリストも必要になります。さらに、これはあるライブラリが別のライブラリのサービスを必要とすることをリストするだけでは不十分です。OOPでは、ライブラリ自体はコンパイル時に認識されない場合があり、システムごとに異なります。
リモートオブジェクト技術は、パーソナルコンピュータ(PC)上で動作するユーザーインターフェースアプリケーションが、メインフレームやミニコンピュータのデータ保存や処理といったサービスを利用する多層プログラムをサポートするために、並行して開発されました。例えば、PC上のプログラムは、比較的大規模なデータセットから比較的小規模なサンプルを取得するために、リモートプロシージャコール(RPC)を介してミニコンピュータにメッセージを送信します。これに対応して、分散オブジェクト技術が開発されました。
クラスライブラリには、オブジェクトの作成に使用できるクラスが含まれています。たとえば、Javaでは、クラスはJARファイルに含まれており、オブジェクトは実行時にクラスから作成されます。一方、Smalltalkでは、クラスライブラリは、環境全体の状態、クラス、およびインスタンス化されたすべてのオブジェクトを含むシステムイメージの開始点となります。ほとんどのクラスライブラリは、パッケージリポジトリ(Javaの場合はMaven Centralなど)に保存されます。クライアントコードは、ビルド構成ファイル(Javaの場合はMaven Pomなど)で外部ライブラリへの依存関係を明示的に指定します。
リモートライブラリは別のコンピュータ上で実行され、その資産にはネットワーク経由のリモートプロシージャコール(RPC)を介してアクセスされます。この分散アーキテクチャにより、各利用システムにおけるライブラリのインストールとサポートを最小限に抑え、バージョン管理の一貫性を確保できます。ただし、大きな欠点は、各ライブラリ呼び出しがローカルライブラリよりも大幅に大きなオーバーヘッドを伴うことです。
ランタイムライブラリは、ホストプラットフォームに合わせて調整された、プログラムで使用できるランタイム環境へのアクセスを提供します。
多くの最新のプログラミング言語では、言語環境に基本レベルの機能を提供する 標準ライブラリが指定されています。
コード生成ライブラリは、 Javaのバイトコードを生成または変換するための高水準APIを備えています。アスペクト指向プログラミング、一部のデータアクセスフレームワーク、そして動的プロキシオブジェクトを生成するためのテストで使用されます。また、フィールドアクセスをインターセプトするためにも使用されます。[ 19 ]
最近のUnix系システムの多くでは、ライブラリファイルは/lib、、、/usr/libなどのディレクトリに保存されます/usr/local/lib。ファイル名は通常、静的ライブラリ(アーカイブ)の場合はlib、、で始まり、共有オブジェクト(動的リンクライブラリ)の場合は、で終わります。例えば、、などです。 .a.solibfoo.alibfoo.so
多くの場合、シンボリックリンクファイルは、バージョン番号のないリンクファイルを提供し、そのリンクファイルをバージョン番号のあるファイルにリンクすることで、ライブラリのバージョン管理に使用されます。例えば、ライブラリfoolibfoo.so.2のバージョンが 2 で、プログラムがリンクするファイルにバージョンに依存しない名前を提供するリンクファイルがあるとします。このリンクファイルをバージョン 3 ( ) を参照するリンクファイルに変更すれば、プログラムを変更することなくバージョン 3 を利用できるようになります。 libfoo.solibfoo.so.3
拡張子を持つファイルはlibtool.laアーカイブであり、システムでは使用できません。
macOSシステムはBSDから静的ライブラリの規約を継承しており、ライブラリは.aファイルに格納されます。動的ライブラリには.soまたは を使用します。ただし、macOSのほとんどのライブラリは「フレームワーク」で構成されており、「バンドル」と呼ばれる特別なディレクトリ内に配置されます。バンドルにはライブラリに必要なファイルとメタデータがラップされています。例えば、 というフレームワークはというバンドルに実装され、 は動的にリンクされたライブラリファイル、または 内の動的にリンクされたライブラリファイルへのシンボリックリンクのいずれかになります。 .dylibAbcAbc.frameworkAbc.framework/AbcAbc.framework/Versions/Current/Abc
多くの場合、Windowsダイナミックリンクライブラリ(DLL)にはファイル拡張子が付きますが.dll、[ 20 ] OLE.ocxライブラリなど、一般的なコンテンツを示すために異なる拡張子が使用されることもあります。
ファイル.libは静的ライブラリであるか、または関連するDLLを使用するアプリケーションをビルドするために必要な情報を含むファイルです。後者の場合、関連するDLLファイルは実行時に存在している必要があります。
サブルーチンの広範な「ライブラリ」を開発することがおそらく非常に重要になるだろう。
バイトコード生成ライブラリは、JAVAバイトコードを生成・変換するための高レベルAPIです。AOP、テスト、データアクセスフレームワークにおいて、動的プロキシオブジェクトの生成やフィールドアクセスのインターセプトに使用されます。
の共有ライブラリは、Windowsのダイナミックリンクライブラリ(DLL)に似ています。WindowsのDLLは通常、ファイル名の拡張子で識別されます.dll。