2010-04-15 26 views
428

Qual è la differenza tra le librerie statiche e condivise?Differenza tra librerie statiche e condivise?

Uso Eclipse e ci sono diversi tipi di progetti, tra cui librerie statiche e librerie condivise? Uno ha un vantaggio rispetto all'altro?

+3

Wikipedia ha una [buona descrizione] (http://en.wikipedia.org/wiki/Library_%28computing%29) della distinzione tra librerie statiche, dinamiche e condivise. –

risposta

595

librerie condivise sono .so (o nei file di Windows .dll o OS X .dylib). Tutto il codice relativo alla libreria si trova in questo file e viene referenziato dai programmi che lo utilizzano in fase di esecuzione. Un programma che utilizza una libreria condivisa fa solo riferimento al codice che utilizza nella libreria condivisa.

Le librerie statiche sono file .a (o in Windows .lib). Tutto il codice relativo alla libreria è in questo file, ed è direttamente collegato al programma in fase di compilazione. Un programma che utilizza una libreria statica prende copie del codice che utilizza dalla libreria statica e lo rende parte del programma. [Windows ha anche.i file lib usati per fare riferimento ai file .dll, ma agiscono allo stesso modo del primo].

Ci sono vantaggi e svantaggi in ciascun metodo.

Le librerie condivise riducono la quantità di codice duplicato in ogni programma che fa uso della libreria, mantenendo i file binari ridotti. Inoltre, consente di sostituire l'oggetto condiviso con uno funzionalmente equivalente, ma potrebbe avere aggiunto vantaggi prestazionali senza la necessità di ricompilare il programma che ne fa uso. Le librerie condivise, tuttavia, hanno un piccolo costo aggiuntivo per l'esecuzione delle funzioni e un costo di caricamento in fase di esecuzione poiché tutti i simboli nella libreria devono essere collegati alle cose che usano. Inoltre, le librerie condivise possono essere caricate in un'applicazione in fase di esecuzione, che è il meccanismo generale per l'implementazione di sistemi di plug-in binari.

Le librerie statiche aumentano la dimensione complessiva del file binario, ma ciò significa che non è necessario portare con sé una copia della libreria in uso. Poiché il codice è collegato in fase di compilazione, non ci sono costi di caricamento aggiuntivi in ​​fase di esecuzione. Il codice è semplicemente lì.

Personalmente, preferisco le librerie condivise, ma uso le librerie statiche quando è necessario assicurarsi che il binario non abbia molte dipendenze esterne che possono essere difficili da soddisfare, come versioni specifiche della libreria standard C++ o versioni specifiche del Boost Libreria C++.

+2

"sostituire l'oggetto condiviso con ... funzionalmente equivalente, ma può [migliorare] le prestazioni": in particolare , funzionalità equivalente di caller-facing nell'uso semantico dell'API (interfaccia di programmazione dell'applicazione: firme e variabili di funzione, inclusi i tipi), ma la funzionalità lato dell'implementazione può differire in più di perfezione: ad esempio la funzione registra sempre su file -> registra anche su TCP server: porta prevista in $ MY_APP_LOG_SERVER. –

+1

"[.sos incorrere in] piccolo costo aggiuntivo per l'esecuzione delle funzioni "- è * possibile * (se i gruppi di funzioni/l'ordine sono stati ottimizzati per la localizzazione della cache nel collegamento statico, o a causa di stranezze in OS/loader/compilatore/architettura come cross-segment/large-pointer perf. penalità), ma su molte architetture/impostazioni del compilatore il linker dinamico aggiusta la chiamata per creare gli stessi opcode della macchina chiamante. –

+2

"Poiché il codice è collegato al momento della compilazione, non ci sono costi di caricamento in fase di esecuzione aggiuntivi. - sì e no ... è tutto nell'immagine eseguibile pronta per essere cercata se l'esecuzione lo richiede, ma - a partire da una situazione in cui il tuo programma non è stato eseguito abbastanza recentemente da essere nella cache - con le librerie condivise è possibile (a volte probabile o certo) che il sistema operativo, un driver o un altro programma in esecuzione avranno già caricato la stessa libreria condivisa che l'app desidera utilizzare, nel qual caso potrebbe trovarsi nella cache e il programma verrà avviato ed eseguito più rapidamente. –

24

Per una libreria statica, il codice viene estratto dalla libreria dal linker e utilizzato per creare l'eseguibile finale nel punto in cui compila/compila la tua applicazione. L'eseguibile finale non ha dipendenze sulla libreria in fase di esecuzione

Per una libreria condivisa, il compilatore/linker verifica che i nomi con cui si collega esistano nella libreria quando l'applicazione viene creata, ma non sposta il loro codice in l'applicazione. In fase di esecuzione, la libreria condivisa deve essere disponibile.

Il linguaggio di programmazione C non ha concetto di librerie statiche o condivise: sono completamente una funzionalità di implementazione.

Personalmente, preferisco di gran lunga utilizzare le librerie statiche, poiché semplifica la distribuzione del software. Tuttavia, questa è un'opinione su cui molto sangue (figurativo) è stato versato in passato.

+3

+1 per "Il linguaggio di programmazione C in sé non ha alcun concetto di librerie statiche o condivise - sono completamente una funzionalità di implementazione."L'immagine eseguibile di – Tiger

14

Il vantaggio più significativo delle librerie condivise è che nella memoria è caricata una sola copia del codice, indipendentemente dal numero di processi che utilizzano la libreria. Per le librerie statiche ogni processo ottiene la propria copia del codice. Ciò può portare a significativi sprechi di memoria.

OTOH, un vantaggio delle librerie statiche è che tutto è integrato nell'applicazione. Quindi non devi preoccuparti che il client abbia la libreria (e la versione) giusta disponibile sul loro sistema.

+1

è più grande su disco, così come in memoria, quando si usano librerie statiche – JustJeff

+0

È corretto, questo è ciò a cui alludevo quando ho detto che tutto è incluso nell'applicazione – Jasmeet

46

semplificata:

  • linking statico: una grande eseguibile
  • dinamica di collegamento: un piccolo eseguibile più uno o più file di libreria (file dll su Windows, .so su Linux, o .dylib su MacOS
26

Le librerie statiche sono compilate come parte di un'applicazione, mentre le librerie condivise no. Quando si distribuisce un'applicazione che dipende da librerie condivise, le librerie, ad es. dll su MS Windows devono essere installati.

I vantaggi delle librerie statiche è che non ci sono dipendenze necessarie per l'utente che esegue l'applicazione - ad es. non devono aggiornare la loro DLL di qualunque cosa ... Gli svantaggi sono che la tua applicazione è di dimensioni maggiori perché la stai spedendo con tutte le librerie di cui ha bisogno.

Oltre che porteranno ad applicazioni più piccole, le librerie condivise offrono all'utente la possibilità di utilizzare il proprio, forse meglio versione delle librerie piuttosto che basarsi su uno che è parte della domanda

+2

DLL come è noto – gheese

+1

"Le librerie statiche sono compilate come parte di un'applicazione" ... le librerie statiche sono compilate come librerie statiche e collegate come parte di un'applicazione – user463035818

323

Una libreria statica è come una libreria e una libreria condivisa è come ... una libreria. Con il primo, si ottiene la propria copia del libro/funzione da portare a casa; con quest'ultimo tu e tutti gli altri andate in biblioteca per usare lo stesso libro/funzione. Quindi chiunque voglia utilizzare la libreria (condivisa) deve sapere dove si trova, perché è necessario "andare a prendere" il libro/la funzione. Con una libreria statica, il libro/la funzione è tua proprietà e tu la tenga nella tua casa/programma, e una volta che ce l'hai non ti importa dove o quando l'hai presa.

2

In cima a tutte le altre risposte, una cosa non ancora menzionate è disaccoppiato:

Permettetemi di parlare di un codice di produzione del mondo reale, che ho avuto a che fare con:

Un grande software, fatto di> 300 progetti (con visual studio), per lo più costruiti come lib statico e infine tutti collegati in un unico enorme eseguibile, si finisce con i seguenti problemi:

-L'intero tempo di connessione è estremamente lungo. Potresti finire con più di 15 minuti di link, diciamo 10 secondi di tempo di compilazione -Alcuni strumenti sono in ginocchio con un eseguibile così grande, come gli strumenti di controllo della memoria che devono strumentare il codice. Potresti cadere nel raggiungere limiti che erano stati visti come pazzi.

Più problematico è il disaccoppiamento del software: in questo esempio reale, i file di intestazioni di ogni progetto erano raggiungibili da qualsiasi altro progetto. Di conseguenza è stato estremamente facile per uno sviluppatore aggiungere dipendenze; si trattava solo di includere l'intestazione, perché il link alla fine mostrerà i simboli. Finisce per l'orribile dipendenza dal ciclismo e il caos completo.

Con la libreria condivisa, è un po 'di lavoro in più perché lo sviluppatore deve modificare il sistema di costruzione del progetto per aggiungere la libreria dipendente. Ho osservato che il codice di libreria condivisa tende ad offrire un'API di codice più pulita.

Problemi correlati