2015-05-12 5 views

risposta

2

. So sono file di libreria condivisi. .a sono file di librerie statiche.

È possibile collegare in modo statico alle librerie .a e collegare e caricare dinamicamente i file .so di runtime, purché vengano compilati e collegati in questo modo.

.o sono file oggetto (ottengono compilati dai file * .c e possono essere collegati per creare eseguibili, .a o .so librerie. Per saperne di più su di esso here

+0

Non c'è anche un modo per caricare librerie .a in fase di esecuzione? – Pacerier

27

.a è un "archivio". Anche se un archivio può contenere qualsiasi tipo di file, nel contesto della toolchain GNU, è una libreria di file oggetto (altre toolchain in particolare su Windows usano lo .lib per lo stesso scopo, ma il formato di questi non è tipicamente un archivio di scopo generale, e spesso specifico per la toolchain) .È possibile estrarre singoli file oggetto da un archivio che è essenzialmente ciò che fa il linker quando usa la libreria.

.o è un file oggetto. Questo è un codice che viene compilato per codice macchina ma non (in genere) completamente collegato - potrebbe avere riferimenti non risolti a simboli definiti in altri file oggetto (in una libreria o singolarmente) generati da una compilazione separata. I file oggetto contengono metadati per supportare il collegamento con altri moduli e facoltativamente anche per il debugging simbolico a livello di origine (ad esempio in GDB). Altre toolchain, sempre in genere su Windows, utilizzano l'estensione .obj anziché .o.

.so è una libreria di oggetti condivisa (o solo una libreria condivisa). Questo è collegato dinamicamente ad un eseguibile quando viene lanciato un programma piuttosto che collegato staticamente al momento della compilazione. Permette di eseguire file eseguibili più piccoli e una singola istanza della libreria di oggetti da utilizzare con più eseguibili. Le API del sistema operativo sono in genere librerie condivise e sono spesso utilizzate anche in GNU per motivi di licenza per separare il codice LGPL da codice proprietario closed-source ad esempio (non sono un avvocato - non sto facendo affermazioni sulla legittimità di questo approccio in qualsiasi situazione particolare). A differenza dei file .o o .a, i file .so utilizzati da un'applicazione devono essere disponibili sul sistema runtime. Altri sistemi (ancora tipicamente Windows) utilizzano lo .dll (libreria di collegamento dinamico) per lo stesso scopo.

E 'forse utile per capire che .o i file sono collegati prima codice oggetto in .a file in modo tale che, se risoluzione simbolo è soddisfatta da un file .o, qualsiasi implementazione libreria non verrà collegata - che consente di sostituire essenzialmente libreria implementazioni con il proprio, e anche per implementazioni di libreria per chiamare il codice definito dall'utente - ad esempio un framework GUI potrebbe chiamare un entry-point dell'applicazione.

+0

Riguardo a "* .o i file sono collegati prima del codice oggetto in .a *", vuoi dire che si verifica in modo irregolare rispetto all'ordine che hai specificato? – Pacerier

1

Le librerie statiche sono archivi che contengono il codice oggetto per la libreria, quando collegati in un'applicazione il cui codice è compilato nell'eseguibile.

Le librerie condivise sono diverse in quanto non vengono compilate nell'eseguibile. Invece il linker dinamico cerca alcune directory alla ricerca della libreria (s) di cui ha bisogno, quindi lo carica in memoria. Più di un eseguibile può utilizzare la stessa libreria condivisa allo stesso tempo, riducendo così l'utilizzo della memoria e le dimensioni dell'eseguibile. Tuttavia, ci sono altri file da distribuire con l'eseguibile. È necessario assicurarsi che la libreria sia installata sul sistema dell'utente da qualche parte dove il linker può trovarla, il collegamento statico elimina questo problema ma risulta in un file eseguibile più grande.

+0

'Tuttavia, ci sono altri file da distribuire con l'eseguibile. Idealmente l'esatto contrario è vero. Pacchetti binari su es. Ovviamente Linux non si porta in giro e prova a installare duplicati di librerie comuni più e più volte. Contrassegnano una dipendenza e obbligano l'utente a installarli. Anche se si distribuisce al di fuori di un gestore di pacchetti, si può spesso presumere che il sistema dell'utente abbia già le librerie richieste o che l'utente possa acquisirle. È soprattutto Windows che spesso rende le cose così difficili da darci dentro e ridistribuire tutte le DLL. Che ... sconfigge un po 'il punto del collegamento dinamico –

Problemi correlati