.a は、1 つ以上の .o elf オブジェクトを含むアーカイブです。 Readelf と objdump はそれらを解析しません。アーカイブから .o ファイルを抽出するには、ar を使用する必要があります。 HAL で 1 つまたは複数の静的ライブラリをラップできる load_elf() のバリアントの記述とデバッグに時間を費やしたい場合は、それらを動的にロードして、呼び出しエントリをイントロスペクトする方法をクライアントに提供できることを理解することが重要です。ポイント。これは非標準的であり、ウォーキング・ジェドのように文学者の痙攣をすでに感じることができます.ただし、ELF には、ライブラリをランタイム環境にドロップし、適切にコーディングされたクライアント関数に、提供された関数へのインターフェイスを検出して呼び出す方法を提供するのに十分な情報が含まれています。これはロケット科学ではありません。それは単に退屈です。ここで重要な概念は、ライブラリの使用を制限しているという考えで .a アーカイブとインクルード スイートを提供する開発者は、単に迷惑であるということです。これは、ライブラリを使用したり、ライブラリがどのように機能するかを発見したりする上で深刻な障害にはなりません。
スタティック ライブラリは、多かれ少なかれ単なるオブジェクト ファイルのコレクションです。プログラムで静的ライブラリを使用する場合は、実行可能ファイルをリンクする必要があります。実行可能ファイルには、静的ライブラリ (または使用したパーツ) が含まれます。
dlopen を使用して実行時に静的ライブラリをロードする場合 、最初に動的ライブラリ libfoo.so を作成する必要があります
.a を開く dlopen を使用したファイル しない 動作します（Ubuntu 10.04でテスト済み）。次のサンプル プログラムでは:
#include <dlfcn.h>
#include <stdio.h>
int main()
{
void *lib_handle = dlopen("/usr/lib/libz.a",RTLD_LAZY);
printf("dlopen error=%s\n",dlerror());
printf("lib_handle=%p\n",lib_handle);
}
私は得る:
dlopen error=/usr/lib/libz.a: invalid ELF header
lib_handle=(nil)
/usr/lib/libz.so を使用する場合 代わりに、次のようになります:
dlopen error=(null)
lib_handle=0x19d6030
したがって、共有オブジェクトに対して同じコードが機能します。