Un .a è un archivio contenente uno o più oggetti .o elf. Readelf e objdump non li analizzeranno. Devi usare ar per estrarre i file .o dall'archivio. È importante rendersi conto che se sei disposto a dedicare del tempo alla scrittura e al debug di una variante di load_elf() che può racchiudere una o più librerie statiche in un HAL, puoi caricarle dinamicamente e fornire ai client un modo per introspezionare la loro voce di chiamata punti. Questo non è standard e posso già sentire i letterati contrarsi come The Walking Jed. Tuttavia, l'ELF contiene informazioni sufficienti per inserire una libreria in un ambiente di runtime e fornire alle funzioni client correttamente codificate un modo per scoprire l'interfaccia alle funzioni fornite e chiamarle. Questa non è scienza missilistica. È semplicemente noioso. Un concetto importante qui è che uno sviluppatore che fornisce l'archivio .a e una suite di include con l'idea che stanno limitando l'uso delle librerie, è solo fastidioso. Non è un serio impedimento all'utilizzo della libreria o alla scoperta di come svolge il suo lavoro.
Una libreria statica è più o meno solo una raccolta di file oggetto. Se vuoi usare una libreria statica in un programma, devi collegare l'eseguibile con essa. L'eseguibile conterrà quindi la libreria statica (o le parti che hai usato).
Se vuoi caricare una libreria statica in fase di esecuzione usando dlopen , dovrai prima creare una libreria dinamica libfoo.so che lo contiene.
Apertura di un .a utilizzando dlopen non funziona (testato su Ubuntu 10.04). Con il seguente programma di esempio:
#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);
}
Ottengo:
dlopen error=/usr/lib/libz.a: invalid ELF header
lib_handle=(nil)
mentre quando si utilizza /usr/lib/libz.so invece, ottengo:
dlopen error=(null)
lib_handle=0x19d6030
quindi lo stesso codice funziona per un oggetto condiviso.