なぜ SO を A に変換するのですか?
開発者が共有ライブラリの .so を静的ライブラリの .a に置き換えるのは、実行時に .so が存在することに依存しない自己完結型のバイナリを作成するためです。これは、ライブラリがインストールされていない可能性のあるマシンにデプロイする場合に便利です。.a はコンパイルされたオブジェクトファイルの ar 形式のアーカイブであり、.so は完全にリンクされた ELF 共有オブジェクトです。どちらも異なる段階で同じソースから構築されます。
SO から A への変換方法
ar (binutils) OPEN-SOURCE
ソースファイルをオブジェクトファイルにコンパイルし(gcc -c -o foo.o foo.c)、次に ar rcs libfoo.a *.o を実行して、それらを静的な .a アーカイブにまとめます。
GCC / Clang OPEN-SOURCE
ライブラリのソースディレクトリで ./configure --enable-static && make を実行して、.so と並行して、あるいはその代わりに .a をビルドします。
apt / dnf / pacman FREE
ライブラリの -dev または -static パッケージ(例:apt install libfoo-dev)をインストールして、ソースからビルドせずにビルド済みの .a を入手します。静的アーカイブは通常 /usr/lib/ に配置されます。
これらの形式について
.soファイルは、LinuxおよびUnixにおける共有オブジェクトライブラリであり、Windowsの.dllに相当するものです。プログラムの実行時に自動的にロードされるため、直接開くことはありません。アプリが «cannot open shared object file»…
.SO の詳細を開く →.a ファイルは、Unix、Linux、および macOS で使用される静的ライブラリです。これはコンパイル済みのオブジェクトファイルを ar 形式でアーカイブしたもので、ビルド時にリンカーによってプログラムにコピーされます。ドキュメントのように開くものではありません。中身を確認するには ar t lib.a(メンバーのリスト表示)や nm…
.A の詳細を開く →品質と注意点
.soは位置独立コード(-fPICでコンパイルされたもの)を使用します。PIC オブジェクトファイルを非 PIE 実行ファイルにリンクされた.aに混ぜると、リンカーの警告が発生することがありますが、通常は動作します。.soファイル名に含まれるバージョン番号(例:libssl.so.3.0.2)に相当するものは.aにはありません。静的ライブラリは SONAME を持ちません。- ソースやパッケージがなく、完成した
.soのみが利用可能な場合、バイナリコンバーターは存在しません。ソースから静的ライブラリを入手またはビルドする必要があります。
よくある質問
`.a` から抽出できるように、`.so` からオブジェクトファイルを抽出することはできますか?
.so のリンク中にマージおよび変更されます。ar x は .a アーカイブに対しては機能しますが、.so ファイルに対しては機能しません。なぜ `.so` の代わりに `.a` を使用するのですか?
.so がインストールされていないシステムでも動作します。これにより、最小限の環境や隔離された環境へのデプロイが簡素化されます。`-dev` パッケージをインストールした後、静的な `.a` はどこに配置されますか?
/usr/lib/x86_64-linux-gnu/libfoo.a に、他のディストリビューションでは同等のライブラリパスに配置されます。