↩ プログラミング言語 gcc GCC は静的リンクライブラリと動的リンクライブラリを使用します。

GCC は静的リンクライブラリと動的リンクライブラリを使用します。

C および C++ プログラムは、ソースファイルから実行可能ファイルまで、前処理、コンパイル、アセンブリ、およびリンクの 4 つの段階を経る必要があることがわかっています。

一般に、リンク段階で行う作業は、同じプロジェクト内の各ソースファイルによって生成されるオブジェクトファイルと、プログラムで使用されるライブラリファイルを実行可能ファイルに統合することです。

以前の gcc (g++) コマンドの体系的な研究を通じて、gcc -c コマンドを使用してソースファイルから対応するターゲットファイルを生成する方法を学びました。では、ライブラリファイルとは何ですか?

いわゆるライブラリファイルは、通常は複数のオブジェクトファイル (つまり、バイナリファイル) を含む圧縮パッケージファイルに相当します。ライブラリファイル内の各オブジェクトファイルに格納されているコードは、完全なプログラムではなく、実用的な機能モジュールであることに注意してください。たとえば、C 言語ライブラリファイルは多数の関数 (scanf()、printf()、strlen() など) を提供し、C++ ライブラリファイルは便利な関数だけでなく、多数の関数も提供します。事前に設計されたクラス (文字列の種類など)。

ライブラリファイルの生成により、多くの関数をゼロから開発する必要がなくなり、関数を含むライブラリファイルを直接呼び出すことができるため、プログラマの開発効率が大幅に向上しました。また、ライブラリファイルの呼び出し方法も非常にシンプルで、C言語のprintf()出力関数を例にとると、プログラムは<stdio.h>ヘッダーファイルをインポートしてprintf()関数を呼び出すだけです。

一部の読者は、なぜライブラリファイルの呼び出しにヘッダーファイルが関係するのかと尋ねるかもしれません。まず、ヘッダーファイルとライブラリファイルは同じものではありません. それらの最大の違いは、ヘッダーファイルは変数、関数、またはクラスなどの機能モジュールの宣言部分のみを格納するのに対し、ライブラリファイルは特定の実装を格納する責任があることです。各モジュールのパーツ。読者はこのように理解できます: すべてのライブラリファイルは、それを呼び出すためのインターフェイスとして、対応するヘッダーファイルを提供します。つまり、ライブラリファイルを直接使用することはできず、ヘッダーファイルを介して間接的に呼び出すことしかできません。

ヘッダーファイルとライブラリファイルを組み合わせたアクセスメカニズムの最大の利点は、実装した関数を他のユーザーに使用してもらいたい場合や、関数のソースコードを公開したくない場合に、関数をライブラリにすることができることです。最も重要なのはバイナリファイルであり、ヘッダーファイルには宣言部分のみが含まれているため、ユーザーの使用に影響を与えることなく「ソースコードを隠す」という目的が達成されます。ライブラリファイルの作り方については、以降の章で詳しく説明します。

実際、ライブラリファイルは、圧縮されたパッケージの一種を指す単なる一般的な用語であり、それらにはすべて機能的で実用的なオブジェクトファイルが含まれています。プログラムのリンク段階でライブラリファイルを使用しますが、コンパイラはリンクを実現する方法として、静的リンク方式と動的リンク方式という 2 つの方法を提供していることに注意してください。リンク動作を実現するための静的リンク方式をスタティック・リンク・ライブラリと呼び、ダイナミック・リンクを利用してリンク動作を実現するライブラリ・ファイルをダイナミック・リンク・ライブラリと呼びます。

では、静的リンクライブラリと動的リンクライブラリの違いは何ですか?

コンテンツ 表示

静的リンクライブラリ

静的リンクライブラリのリンク操作を実現する方法は非常に簡単です。つまり、ライブラリファイル内の関数モジュールがプログラムファイルで使用されている場合、GCC コンパイラはテンプレートコードをプログラムの適切な位置に直接コピーします。ファイルを作成し、最後に実行可能ファイルを生成します。

スタティックライブラリファイルを使用してプログラムのリンク操作を実現することには、次のような利点と欠点があります。

利点は、生成された実行可能ファイルが静的ライブラリファイルのサポートなしで独立して実行できることです (強力な移植性)。
欠点は、ライブラリ内の同じ関数モジュールがプログラムファイルで複数回呼び出される場合、モジュールコードが複数回コピーされることは避けられず、生成された実行可能ファイルには複数の同一コードが含まれ、コードの冗長性が生じることです。

ダイナミックリンクライブラリを使用して生成された実行ファイルと比較して、スタティックリンクライブラリで生成された実行ファイルはサイズが大きくなります。

また、Linux ディストリビューションシステムでは、スタティックリンクライブラリファイルのサフィックスは通常 .a で表され、Windows システムではスタティックリンクライブラリファイルのサフィックスは .lib であることにも注意してください。

ダイナミックリンクライブラリ

共有リンクライブラリとも呼ばれるダイナミックリンクライブラリ。スタティックリンクライブラリとは異なり、ダイナミックリンクライブラリを使用してリンク操作を実現する場合、プログラムファイルでライブラリファイルの関数モジュールが必要な場合、GCC コンパイラは関数モジュールのコードを直接にコピーしません。ファイルですが、機能モジュールの位置情報はファイルに記録され、実行可能ファイルが直接生成されます。

明らかに、この方法で生成された実行可能ファイルは、単独では実行できません。ダイナミックリンクライブラリによって生成された実行ファイルが実行されると、GCC コンパイラは、対応するダイナミックリンクライブラリを一緒にメモリにロードします. 実行ファイルには、必要な機能モジュールの位置情報が事前に記録されているため、既存のダイナミックリンクとライブラリのサポートにより、正常に実行することもできます。

プログラムの接続操作を実現するために動的リンクライブラリを使用する利点と欠点は、静的リンクライブラリの場合と正反対です。

利点は、汎用モジュールのアドレスが実行可能ファイルに記録されるため、プログラムの実行時に実際の実装コードがメモリにロードされることです。これは、汎用モジュールが複数回呼び出されても、同じ実装が行われることを意味します。コードが使用されます (これが、ダイナミックリンクライブラリが共有リンクライブラリと呼ばれる理由でもあります)。
欠点は、この方法で生成された実行可能ファイルは独立して実行できず、対応するライブラリファイルに依存する必要があることです (移植性が低い)。

静的リンクライブラリを使用して生成された実行可能ファイルと比較して、動的リンクライブラリによって生成された実行可能ファイルは、冗長なコードの束が内部にコピーされないため、サイズが小さくなります。

Linux ディストリビューションシステムでは、ダイナミックリンクライブラリのサフィックスは通常 .so で表され、Windows システムでは、ダイナミックリンクライブラリのサフィックスは .dll です。

なお、GCC コンパイラが実行ファイルを生成する際、デフォルトではダイナミックリンクライブラリを使用してリンク操作を実現することを優先しますが、現在のシステム環境にプログラムファイルに必要なダイナミックリンクライブラリがない場合を除き、 GCC コンパイラは、対応する静的リンクライブラリを選択します。どちらも存在しない場合 (または GCC コンパイラーによって検出されない場合)、リンクは失敗します。

Linux ディストリビューションでは、静的リンクライブラリと動的リンクライブラリは通常、/usr/bin または /bin ディレクトリに格納されます。図 1 は、CentOS システムの /usr/bin ディレクトリにあるシステムライブラリファイルの格納状態を示しています。

実際の開発では、リンクライブラリファイルを使用するだけでなく、スタティックリンクライブラリまたはダイナミックリンクライブラリを自分でカスタマイズすることもできます。リンクライブラリファイルの具体的な作成と使用については、以降の章で詳しく説明します。