Perchè creare un file .a da .o per il collegamento statico?

Question

Si consideri questo codice:

one.c:

#include <stdio.h>

int one() {
   printf("one!\n");
   return 1;
}

two.c:

#include <stdio.h>

int two() {
   printf("two!\n");
   return 2;
}

prog.c

#include <stdio.h>

int one();
int two();

int main(int argc, char *argv[]) 
{
   one();
   two();

   return 0;
}

Voglio collegare questi programmi insieme. Così faccio questo:

gcc -c -o one.o one.c
gcc -c -o two.o two.c
gcc -o a.out prog.c one.o two.o

Questo funziona bene.

O potrei creare una libreria statica:

ar rcs libone.a one.o
ar rcs libtwo.a two.o
gcc prog.c libone.a libtwo.a
gcc -L. prog.c -lone -ltwo

Quindi la mia domanda è: perché vorrei utilizzare la seconda versione - quella in cui ho creato un file ".a" - invece di collegare i miei file ".o"? Entrambi sembrano essere che collega in modo statico, quindi c'è un vantaggio o differenza di architettura in uno contro l'altro?

Answer 1

In genere le librerie sono collezioni di file di oggetti che possono essere utilizzati in più programmi.

Nel tuo esempio non c'è alcun vantaggio, ma voi avranno fatto:

ar rcs liboneandtwo.a one.o two.o

Poi collega il programma diventa più semplice:

gcc -L. prog.c -loneandtwo

E 'davvero una questione di packaging. Avete una serie di file oggetto che si formano naturalmente una serie di funzionalità correlate che possono essere riutilizzati in più programmi? Se è così, allora possono ragionevolmente essere archiviati in una libreria statica, altrimenti probabilmente non ha alcun vantaggio.

C'è una differenza importante nella fase di collegamento finale. Tutti i file oggetto che è legata saranno inclusi nel programma finale. file oggetto che si trovano in biblioteche sono inclusi solo se aiutano a risolvere eventuali simboli non definiti in altri file oggetto. Se non lo fanno, non saranno collegati in eseguibile finale.

Answer 2

La differenza sarebbe nella dimensione del file eseguibile, anche se forse non per il tuo esempio.

Quando si collega ad una libreria, solo i bit che vengono utilizzati dal vostro eseguibile sono incorporati. Quando si collega un file oggetto, si prende l'intera faccenda.

Per esempio, se il file eseguibile doveva includere ogni funzione matematica nella libreria matematica quando si utilizza una sola, sarebbe molto più grande di quello che doveva essere e contengono un sacco di codice non utilizzato.

E 'interessante confrontare questo con il modello di collegamento dinamico di Windows. Lì, il sistema operativo deve caricare tutte le DLL (librerie a collegamento dinamico) del tutto che i vostri usi eseguibili, che potrebbero portare a gonfiare in RAM. Il vantaggio di tale modello è che l'eseguibile è di per sé più piccolo, e le DLL collegate potrebbe essere già in memoria utilizzata da qualche altro eseguibile, in modo che non c'è bisogno di essere caricato di nuovo.

In collegamento statico, le funzioni di libreria vengono caricati separatamente per ogni file eseguibile.

Answer 3

Tecnicamente, il risultato è esattamente lo stesso. Di solito, è creare librerie per funzioni di utilità, così invece di alimentare il linker con decine di file oggetto, devi solo collegare la libreria.

A proposito, assolutamente non ha senso per creare un file .a che contiene soltanto un file .o.

Answer 4

Si può mettere una raccolta di file in un archivio (.a) file per un successivo riutilizzo. La libreria standard è un buon esempio.

A volte ha senso per organizzare grandi progetti in librerie.

Answer 5

Il vantaggio principale è quando si deve collegare, è possibile specificare solo una libreria, invece di tutti i file oggetto separati. C'è anche un vantaggio minore in gestione dei file, ottenendo a che fare con una libreria, invece di un gruppo di file oggetto. Un tempo, questo ha anche dato un notevole risparmio in spazio su disco, ma i prezzi attuali del disco rigido fare quella meno importante.

Answer 6

Ogni volta che mi viene chiesto questa domanda (da matricole nella mia squadra), "perché (o talvolta anche un 'ciò che è') un .a?", Io uso la risposta qui sotto che utilizza il .zip come analogia.

"Una dotAy è come un file zip di tutti i dotOhs che si vorrebbe collegare mentre la costruzione il tuo exe / lib. Risparmio spazio su disco, più uno non è necessario digitare i nomi di tutte le dotOhs coinvolti".

finora, questo è sembrato di far capire loro. ;)