.oはオブジェクトファイル、.aは静的ライブラリ、.soは動的ライブラリを知っていますか?彼らの身体的意義は何ですか?いつ使用できますか?
.a
は「アーカイブ」です。アーカイブには任意の種類のファイルを含めることができますが、GNUツールチェーンのコンテキストでは、オブジェクトファイルのライブラリです(特にWindowsの他のツールチェーンは、同じ目的で.lib
を使用します、しかし、これらの形式は通常、一般的な目的のアーカイブではなく、多くの場合、ツールチェーンに固有です)アーカイブから個々のオブジェクトファイルを抽出することは可能です。
.o
はオブジェクトファイルです。これは、マシンコードにコンパイルされますが、(通常)完全にリンクされていないコードです。別のコンパイルによって生成された(ライブラリまたは個別の)他のオブジェクトファイルで定義されたシンボルへの未解決の参照があります。オブジェクトファイルには、他のモジュールとのリンクをサポートするメタデータが含まれています。また、オプションでソースレベルのシンボリックデバッグ(GDBなど)もサポートされています。他のツールチェーンは、通常はWindowsでも、.obj
ではなく.o
という拡張子を使用します。
.so
は共有オブジェクトライブラリ(または単に共有ライブラリ)です。これは、ビルド時に静的にリンクされるのではなく、プログラムの起動時に実行可能ファイルに動的にリンクされます。これにより、より小さな実行可能ファイルと、単一のオブジェクトライブラリインスタンスを複数の実行可能ファイルで使用できます。オペレーティングシステムAPIは通常、共有ライブラリであり、GNUなどで使用されます。たとえば、LGPLコードをクローズドソースのプロプライエタリコードから分離するためです(私は弁護士ではありません。 .o
または.a
ファイルとは異なり、アプリケーションで使用される.so
ファイルはランタイムシステムで利用可能である必要があります。通常、Windows)同じ目的で.dll
(ダイナミックリンクライブラリ)を使用します。
.o
ファイルがリンクされていることを理解しておくと便利でしょう。before.a
ファイル内のオブジェクトコードは、シンボル解決が.o
ファイルによって満たされる場合、ライブラリ実装はリンクされません-ライブラリ実装を基本的に独自のものに置き換えたり、ライブラリ実装でユーザー定義コードを呼び出すことができます-たとえば、GUIフレームワークはアプリケーションのエントリポイントを呼び出す場合があります。
静的ライブラリは、コードが実行可能ファイルにコンパイルされるアプリケーションにリンクされている場合、ライブラリのオブジェクトコードを含むアーカイブです。
共有ライブラリは、実行可能ファイルにコンパイルされないという点で異なります。代わりに、動的リンカーはいくつかのディレクトリを検索して必要なライブラリを探し、それをメモリにロードします。複数の実行可能ファイルが同じ共有ライブラリを同時に使用できるため、メモリ使用量と実行可能ファイルのサイズが削減されます。ただし、実行可能ファイルとともに配布するファイルがさらにあります。ライブラリがリンカーを見つけることができるユーザーのシステムにインストールされていることを確認する必要があります。静的リンクはこの問題を排除しますが、実行可能ファイルは大きくなります。
.soは共有ライブラリファイルです。 .aは静的ライブラリファイルです。
.aライブラリに静的にリンクし、実行時に.soファイルを動的にリンクおよびロードできます(そのようにコンパイルおよびリンクする場合)。
.oはオブジェクトファイルです(* .cファイルからコンパイルされ、実行可能ファイル、.aまたは.soライブラリを作成するためにリンクできます。詳細についてはこちらを参照してください here