図書館(コンピューティング)

コンピュータサイエンスにおいて、ライブラリとは、ソフトウェア開発中にコンピュータプログラムを実装するために活用される読み取り専用リソースの集合です。
歴史的に、ライブラリはサブルーチン(今日では一般的に関数と呼ばれます) で構成されていました。現在、この概念には、クラスなどの他の形式の実行可能コードと、画像やテキストなどの非実行可能データが含まれます。また、ソース コードのコレクションを指すこともあります。
たとえば、プログラムは、プログラム内で直接システム コールを実行する代わりに 、ライブラリを使用して間接的にシステム コールを実行することができます。
特徴
一般的な
ライブラリは、複数の独立したコンシューマー (プログラムや他のライブラリ) によって使用できます。これは、通常そのプログラムでのみ使用できるプログラムで定義されたリソースとは異なります。
消費者がライブラリ リソースを使用すると、ライブラリ自体を実装しなくてもライブラリの価値を得ることができます。ライブラリは、モジュール形式でのコードの再利用を促進します。
ライブラリを使用するコードを書くとき、プログラマーはライブラリの内部詳細すべてを知る必要はなく、ライブラリに含まれる項目やその項目の使用方法などの高レベルの情報のみを知る必要があります。
ライブラリは他のライブラリを使用できるため、プログラム内にライブラリの階層が形成されます。
実行可能
実行可能コードのライブラリには、機能が呼び出される明確に定義されたインターフェースがあります。たとえば、Cでは、ライブラリ関数はCの通常の関数呼び出し機能を介して呼び出されます。リンカーは、関数がプログラム自体ではなくライブラリから利用できる場合、ライブラリメカニズムを介して関数を呼び出すコードを生成します。[1]
ライブラリの関数は、プログラムのライフサイクルのさまざまな段階で呼び出しプログラムに接続できます。呼び出しプログラムのビルド中にライブラリのコードがアクセスされる場合、ライブラリは静的ライブラリと呼ばれます。[2]別の方法として、プログラムの実行可能ファイルをライブラリファイルとは別にビルドする方法があります。ライブラリ関数は、実行可能ファイルが起動された後、ロード時または実行時に接続されます。この場合、ライブラリは動的ライブラリと呼ばれます。
ほとんどのコンパイル言語には標準ライブラリがありますが、プログラマーは独自のカスタムライブラリを作成することもできます。ほとんどの最新のソフトウェア システムは、システム サービスの大部分を実装するライブラリを提供しています。このようなライブラリは、最新のアプリケーションに必要なサービスを整理しています。そのため、最新のアプリケーションで使用されるほとんどのコードは、これらのシステム ライブラリで提供されています。
歴史
コンピュータ ライブラリのアイデアは、チャールズ バベッジが最初に作成したコンピュータにまで遡ります。1888 年に発表された解析エンジンに関する論文では、コンピュータ操作を数値入力とは別のカードにパンチできると示唆されていました。これらの操作パンチ カードが再利用のために保存されていれば、「エンジンは徐々に独自のライブラリを持つようになるでしょう。」[3]

1947年、ゴールドスタインとフォン・ノイマンは、当時まだ動作していなかった初期のコンピュータであるIASマシンでの作業にサブルーチンの「ライブラリ」を作成することが有用であると推測しました。 [4]彼らは、磁気ワイヤ記録の物理的なライブラリを構想し、各ワイヤに再利用可能なコンピュータコードが格納されました。[5]
フォン・ノイマンに触発されて、ウィルクスと彼のチームはEDSACを構築した。パンチテープのファイリングキャビネットには、このコンピュータのサブルーチンライブラリが保管されていた。[6] EDSACのプログラムは、メインプログラムとサブルーチンライブラリからコピーされた一連のサブルーチンで構成されていた。[7] 1951年にチームはプログラミングに関する最初の教科書である『電子デジタルコンピュータのプログラムの準備』を出版し、ライブラリの作成と目的を詳しく説明した。[8]
COBOLには1959年に「ライブラリシステムのための基本的な機能」が含まれていたが[ 9] 、 Jean Sammetはそれを振り返って「不十分なライブラリ機能」と評した[10] 。
JOVIAL には、ヘッダー ファイルのライブラリとも言える通信プール (COMPOOL) があります。
現代のライブラリの概念に大きく貢献したもう1つの要因は、FORTRANのサブプログラムの革新でした。FORTRANのサブプログラムは互いに独立してコンパイルできますが、コンパイラにはリンカーがありませんでした。そのため、Fortran-90でモジュールが導入される前は、FORTRAN [NB 1]サブプログラム間の型チェックは不可能でした。[11]
1960 年代半ばまでに、アセンブラのコピー ライブラリとマクロ ライブラリが一般的になりました。IBM System/360の普及に伴い、システム パラメータなどの他の種類のテキスト要素を含むライブラリも一般的になりました。
IBM の OS/360 およびその後継製品では、これをパーティション データ セットと呼びます。
1965年に開発された最初のオブジェクト指向プログラミング言語であるSimulaは、コンパイラを介してライブラリに クラスを追加することをサポートしていました。 [12] [13]
リンク
ライブラリは、リンクまたはシンボルと呼ばれる参照をライブラリ モジュールに解決するプログラムのリンクまたはバインディングプロセスで重要です。リンク プロセスは通常、一連のライブラリとその他のモジュールを指定された順序で検索するリンカーまたはバインダープログラムによって自動的に実行されます。通常、指定された一連のライブラリでリンク ターゲットが複数回見つかった場合、エラーとは見なされません。リンクは、実行可能ファイルの作成時 (静的リンク) またはプログラムが実行時に使用されるたびに(動的リンク) 実行されます。
解決される参照は、ジャンプやその他のルーチン呼び出しのアドレスである可能性があります。これらはメイン プログラム内にある場合もあれば、あるモジュールが別のモジュールに依存している場合もあります。参照される各モジュールのメモリ セグメントにランタイム メモリを割り当てることによって、これらは固定アドレスまたは再配置可能アドレス (共通ベースから) に解決されます。
一部のプログラミング言語では、スマート リンクと呼ばれる機能を使用します。この機能では、リンカーがコンパイラを認識したり、コンパイラと統合したりして、外部参照の使用方法を認識し、内部参照されていても実際には使用されないライブラリ内のコードを、コンパイルされたアプリケーションから破棄できます。たとえば、算術演算に整数のみを使用するプログラム、または算術演算をまったく行わないプログラムでは、浮動小数点ライブラリ ルーチンを除外できます。このスマート リンク機能により、アプリケーション ファイルのサイズが小さくなり、メモリ使用量が削減されます。
移転
プログラムまたはライブラリ モジュール内の一部の参照は、相対形式またはシンボリック形式で保存されます。これらの参照は、すべてのコードとライブラリに最終的な静的アドレスが割り当てられるまで解決できません。再配置は、これらの参照を調整するプロセスであり、リンカーまたはローダーによって実行されます。一般に、メモリ内のアドレスは、それらを使用するプログラムや、それらが結合される他のライブラリによって異なる可能性があるため、個々のライブラリ自体に対して再配置を行うことはできません。位置非依存コードでは、絶対アドレスへの参照が回避されるため、再配置は必要ありません。
静的ライブラリ
実行可能ファイルまたは別のオブジェクトファイルの作成中にリンクが行われる場合、それは静的リンクまたは早期バインディングと呼ばれます。この場合、リンクは通常リンカーによって行われますが、コンパイラによって行われる場合もあります。[14]静的ライブラリはアーカイブとも呼ばれ、静的にリンクされることを意図したものです。もともと、静的ライブラリのみが存在していました。モジュールを再コンパイルする場合は、必ず静的リンクを実行する必要があります。
プログラムに必要なすべてのモジュールは、静的にリンクされ、実行ファイルにコピーされることがあります。このプロセスと、その結果として生成されるスタンドアロンファイルは、プログラムの静的ビルドと呼ばれます。仮想メモリが使用され、アドレス空間レイアウトのランダム化が望ましくない場合、静的ビルドではそれ以上の再配置は必要ありません。 [15]
共有ライブラリ
共有ライブラリまたは共有オブジェクトは、実行可能ファイルとその他の共有オブジェクト ファイルによって共有されることを意図したファイルです。プログラムによって使用されるモジュールは、プログラムの単一のモノリシックな実行可能ファイルを作成するときにリンカーによってコピーされるのではなく、ロード時または実行時に個々の共有オブジェクトからメモリにロードされます。
共有ライブラリはコンパイル時に静的にリンクできます。つまり、実行可能ファイルの作成時にライブラリ モジュールへの参照が解決され、モジュールにメモリが割り当てられます。[引用が必要]ただし、共有ライブラリのリンクは、ロードされるまで延期されることがよくあります。[疑わしい–議論]
オブジェクトライブラリ
動的リンクは 1960 年代に最初に開発されましたが、最も一般的に使用されているオペレーティングシステムに導入されたのは 1980 年代後半でした。1990 年代初頭までには、ほとんどのオペレーティング システムで何らかの形で一般的に使用できるようになりました。この同じ時期に、オブジェクト指向プログラミング(OOP) がプログラミング環境の重要な部分になりつつありました。実行時バインディングを備えた OOP では、従来のライブラリでは提供されない追加の情報が必要です。内部にあるコードの名前とエントリ ポイントに加えて、依存するオブジェクトのリストも必要です。これは、OOP のコア概念の 1 つである継承の副作用であり、メソッドの完全な定義の一部が異なる場所にある可能性があります。これは、1 つのライブラリが別のライブラリのサービスを必要とすることを単に示す以上のことです。真の OOP システムでは、ライブラリ自体はコンパイル時に認識されない場合があり、システムごとに異なります。
同時に、多くの開発者が、デスクトップ コンピュータで実行されている「ディスプレイ」が、データの保存や処理にメインフレームまたはミニコンピュータのサービスを使用する、多層プログラムのアイデアに取り組んでいました。たとえば、GUI ベースのコンピュータ上のプログラムは、ミニコンピュータにメッセージを送信し、巨大なデータセットの小さなサンプルを返して表示します。リモート プロシージャ コール(RPC) はすでにこれらのタスクを処理していましたが、標準的な RPC システムはありませんでした。
すぐに、ミニコンピュータとメインフレームのベンダーの大半が、この 2 つを統合するプロジェクトを立ち上げ、どこでも使用できる OOP ライブラリ形式を作成しました。このようなシステムは、リモート アクセスをサポートしている場合はオブジェクト ライブラリ、または分散オブジェクトと呼ばれていました (すべてをサポートしているわけではありません)。Microsoft の COM は、ローカルで使用するこのようなシステムの一例です。COM の修正バージョンである DCOM は、リモート アクセスをサポートしています。
しばらくの間、オブジェクト ライブラリはプログラミングの世界における「次なる大物」の地位を占めていました。プラットフォーム間で動作するシステムを作成するための取り組みが数多く行われ、企業は開発者を自社のシステムに縛り付けようと競い合いました。例としては、IBMのSystem Object Model (SOM/DSOM)、Sun MicrosystemsのDistributed Objects Everywhere (DOE)、NeXTのPortable Distributed Objects (PDO)、Digitalの ObjectBroker、Microsoft のComponent Object Model (COM/DCOM)、および数多くのCORBAベースのシステムがあります。
クラスライブラリ
クラス ライブラリは、古いタイプのコード ライブラリの OOP 版です。クラス ライブラリには、特性を記述し、オブジェクトに関連するアクション (メソッド) を定義するクラスが含まれています。クラス ライブラリは、特性が特定の値に設定されたオブジェクト、つまりインスタンスを作成するために使用されます。 Javaなどの一部の OOP 言語では、クラスはライブラリ ファイル (Java のJAR ファイル形式など) に含まれることが多く、インスタンス化されたオブジェクトはメモリ内にのみ存在します (ただし、別のファイルに永続化することは可能です)。 Smalltalkなどの他の言語では、クラス ライブラリは、環境の状態全体、クラス、およびインスタンス化されたすべてのオブジェクトを含むシステム イメージの開始点にすぎません。
現在、ほとんどのクラス ライブラリはパッケージ リポジトリ(Java の Maven Central など)に保存されています。クライアント コードは、ビルド構成ファイル (Java の Maven Pom など) で外部ライブラリへの依存関係を明示的に宣言します。
リモートライブラリ
別のライブラリ技術では、完全に独立した実行可能ファイル (多くの場合、軽量形式) を使用し、ネットワーク経由で別のコンピュータにリモート プロシージャ コール(RPC) を使用して呼び出します。これにより、オペレーティング システムの再利用が最大化されます。ライブラリをサポートするために必要なコードは、他のすべてのプログラムにアプリケーション サポートとセキュリティを提供するために使用されているコードと同じです。さらに、このようなシステムでは、ライブラリが同じマシンに存在する必要はなく、ネットワーク経由で要求を転送できます。
ただし、このようなアプローチでは、ライブラリ呼び出しごとにかなりのオーバーヘッドが必要になります。RPC 呼び出しは、同じマシンにすでにロードされている共有ライブラリを呼び出すよりもはるかにコストがかかります。このアプローチは、このようなリモート呼び出しを頻繁に使用する分散アーキテクチャ、特にクライアント サーバー システムやEnterprise JavaBeansなどのアプリケーション サーバーでよく使用されます。
コード生成ライブラリ
コード生成ライブラリは、 Javaのバイトコードを生成または変換できる高水準APIです。アスペクト指向プログラミング、一部のデータアクセスフレームワーク、および動的プロキシオブジェクトを生成するテストで使用されます。また、フィールドアクセスを傍受するためにも使用されます。[16]
ファイル名
最近のUnix系システムのほとんど
システムは、ファイルlibfoo.a
とファイルを、、またはなどlibfoo.so
のディレクトリに保存します。ファイル名は常に、で始まり、 (アーカイブ、静的ライブラリ)または(共有オブジェクト、動的リンク ライブラリ)のサフィックスで終わります。一部のシステムでは、動的リンク ライブラリに複数の名前が付けられることがあります。これらの名前は通常、同じプレフィックスを共有し、バージョン番号を示す異なるサフィックスを持ちます。名前のほとんどは、最新バージョンへのシンボリック リンクの名前です。たとえば、一部のシステムでは、動的リンク ライブラリの 2 番目のメジャー インターフェイス リビジョンのファイル名は になります。ライブラリ ディレクトリで時々見つかるファイルはlibtoolアーカイブであり、システムでそのまま使用することはできません。
/lib
/usr/lib
/usr/local/lib
lib
.a
.so
libfoo.so.2
libfoo
.la
macOS
システムは、BSDから静的ライブラリ規則を継承し、ライブラリを.a
ファイルに保存し、.so
スタイルの動的リンク ライブラリ (.dylib
代わりにサフィックスを使用) を使用できます。ただし、macOS のほとんどのライブラリは「フレームワーク」で構成されており、「バンドル」と呼ばれる特別なディレクトリ内に配置され、ライブラリに必要なファイルとメタデータがラップされます。たとえば、と呼ばれるフレームワークは、MyFramework
と呼ばれるバンドルに実装されMyFramework.framework
、 はMyFramework.framework/MyFramework
動的リンク ライブラリ ファイルであるか、 内の動的リンク ライブラリ ファイルへのシンボリック リンクになりますMyFramework.framework/Versions/Current/MyFramework
。
マイクロソフトウィンドウズ
ダイナミックリンクライブラリに*.DLL
は通常、サフィックスが付きます。 [17]ただし、他のファイル名拡張子は、OLE*.OCX
ライブラリなど、特定目的のダイナミックリンクライブラリを識別する場合があります。インターフェイスのリビジョンは、ファイル名にエンコードされるか、COMオブジェクトインターフェイスを使用して抽象化されます。コンパイル方法に応じて、ファイルは静的ライブラリ、またはコンパイル時にのみ必要な動的リンク可能なライブラリの表現(「インポートライブラリ」と呼ばれます)のいずれかになります。異なるファイル拡張子を使用するUNIXの世界とは異なり、 Windowsでファイルをリンクする場合は、まずそれが通常の静的ライブラリであるかインポートライブラリであるかを認識する必要があります。後者の場合、ファイルは実行時に存在する必要があります。
*.LIB
.LIB
.DLL
参照
- コードの再利用 – 既存のソフトウェアを使用して新しいソフトウェアを構築する
- リンカー(コンピューティング) – 複数のオブジェクトファイルを1つのファイルに結合するコンピュータプログラム
- ローダー(コンピューティング) – オペレーティングシステムの一部
- ダイナミックリンクライブラリ - Windows および OS/2 における共有ライブラリの概念の Microsoft による実装
- オブジェクトファイル – 再配置可能な形式のマシンコードを含むファイル
- プラグイン – 既存のソフトウェア アプリケーションに特定の機能を追加するソフトウェア コンポーネント
- プレリンク(プレバインディングとも呼ばれる)
- 静的ライブラリ – コンピュータサイエンスにおけるルーチン、外部関数、変数のセット
- ランタイムライブラリ – ソフトウェアライブラリの種類
- ビジュアル コンポーネント ライブラリ – Windows 用 Object Pascal フレームワーク (VCL)
- クロスプラットフォーム向けコンポーネントライブラリ(CLX)
- C 標準ライブラリ – C プログラミング言語の標準ライブラリ
- Java クラス ライブラリ – Java およびその他の JVM プログラミング言語の標準ライブラリ
- フレームワーク クラス ライブラリ – Microsoft の .NET Framework の標準ライブラリ
- ジェネリックプログラミング – コンピュータプログラミングのスタイル(C++ 標準ライブラリで使用)
- soname – 共有オブジェクトファイル内のデータのフィールド
- メソッドスタブ – メソッドの短くてシンプルなバージョン
注記
- ^ 以前は、たとえば Ada サブプログラム間では可能でした。
参考文献
- ^ Deshpande, Prasad (2013).関数呼び出しグラフ分析を使用したメタモルフィック検出(論文). サンノゼ州立大学図書館. doi : 10.31979/etd.t9xm-ahsc .
- ^ 「静的ライブラリ」。TLDP。2013年7月3日時点のオリジナルよりアーカイブ。2013年10月3日閲覧。
- ^ Babbage, HP (1888-09-12). 「解析エンジン」。英国協会紀要。バース。
- ^ゴールドスタイン、ハーマン H. ( 2008-12-31). パスカルからフォン・ノイマンまでのコンピュータ。プリンストン: プリンストン大学出版局。doi : 10.1515/9781400820139。ISBN 978-1-4008-2013-9。
- ^ Goldstine, Herman ; von Neumann, John (1947). 電子計算機器の問題の計画とコーディング (レポート). Institute for Advanced Study. pp. 3, 21–22. OCLC 26239859.
サブルーチンの広範な「ライブラリ」を開発することがおそらく非常に重要になるだろう。
- ^ Wilkes, MV ( 1951)。「EDSAC コンピュータ」。1951国際要件知識管理ワークショップ。1951 国際要件知識管理ワークショップ。IEEE。p. 79。doi :10.1109/afips.1951.13。
- ^ Campbell-Kelly, Martin (2011年9月). 「『ウィルクス、ウィーラー、ギル』を讃えて」Communications of the ACM . 54 (9): 25–27. doi :10.1145/1995376.1995386. S2CID 20261972.
- ^ ウィルクス、モーリス、ホイーラー、デイビッド、ギル、スタンレー(1951) 。電子デジタルコンピュータ用プログラムの作成。アディソン・ウェスレー。pp. 45、80–91、100。OCLC 641145988。
- ^ Wexelblat, Richard (1981). プログラミング言語の歴史. ACM モノグラフシリーズ. ニューヨーク: Academic Press ( Harcourt Braceの子会社). p. 274. ISBN 0-12-745040-8。
- ^ ヴェクセルブラット、op.引用。、p. 258
- ^ Wilson, Leslie B.; Clark, Robert G. (1988). Comparison Programming Languages . ウォキンガム、イギリス: Addison-Wesley. p. 126. ISBN 0-201-18483-4。
- ^ ウィルソンとクラーク、前掲書、52ページ
- ^ ヴェクセルブラット、op.引用。、p. 716
- ^ Kaminsky, Dan (2008). 「第 3 章 - ポータブル実行可能ファイルと 実行可能ファイルおよびリンク形式」IDA Pro によるコードのリバース エンジニアリングエルゼビア。pp. 37–66。doi :10.1016/b978-1-59749-237-9.00003- x。ISBN 978-1-59749-237-9. 2021年5月27日閲覧。
- ^ Collberg, Christian; Hartman, John H.; Babu, Sridivya; Udupa, Sharath K. (2003). SLINKY: Static Linking Reloaded. USENIX '05. Department of Computer Science, University of Arizona . 2016-03-23 時点のオリジナルよりアーカイブ。 2016-03-17に取得。
- ^ 「コード生成ライブラリ」。Source Forge。2010年 1 月 12 日にオリジナルからアーカイブ。2010 年 3 月 3 日に取得。
バイト コード生成ライブラリは、JAVA バイト コードを生成および変換するための高レベル API です。AOP、テスト、データ アクセス フレームワークによって、動的プロキシ オブジェクトを生成し、フィールド アクセスをインターセプトするために使用されます。
- ^ Bresnahan, Christine; Blum, Richard (2015-04-27). LPIC-1 Linux Professional Institute Certification Study Guide: Exam 101-400 and Exam 102-400. John Wiley & Sons (2015 年発行). p. 82. ISBN
9781119021186. 2015-09-24 にオリジナルからアーカイブされました。2015-09-03に取得。
Linux 共有ライブラリは、Windows のダイナミック リンク ライブラリ (DLL) に似ています。 Windows DLL は通常、
.dll
ファイル名拡張子によって識別されます。
さらに読む
- Levine, John R. (2000) [1999 年 10 月]。「第 9 章: 共有ライブラリと第 10 章: 動的リンクとロード」。リンカーとローダー。Morgan Kaufmann ソフトウェア エンジニアリングおよびプログラミングシリーズ (第 1 版)。サンフランシスコ、米国: Morgan Kaufmann。ISBN 1-55860-496-0. OCLC 42413382. 2012年12月5日にオリジナルからアーカイブ。2020年1月12日閲覧。コード: [1][2] エラッタ: [3]
- 記事リンカー初心者ガイド(David Drysdale 著)
- 記事ランタイムリンクの効率性を改善して C++ プログラムの起動を高速化する ( Léon Bottou と John Ryland 著)
- プログラムライブラリの作成方法 (Baris Simsek 著)
- BFD - バイナリ ファイル記述子ライブラリ
- 第 1 回ライブラリ中心のソフトウェア設計ワークショップ LCSD'05 は、2019 年 8 月 28 日にWayback Machineの OOPSLA'05にアーカイブされました。
- 第 2 回ライブラリ中心のソフトウェア設計ワークショップ LCSD'06 (OOPSLA'06 にて)
- Ulrich Drepper による共有ライブラリの作成方法 (詳細な背景情報付き)
- IBM.com の Linux 動的ライブラリの分析