Le librerie statiche C sono disapprovate? [chiuso]

La premessa della tua domanda è errata. Ciò che è disapprovato è attenersi a dottrinari e assoluti senza alcuna comprensione delle basi dietro di loro (Cargo Cult Programming?).

La risposta SO collegata è uno studio interessante proprio in questo argomento- la domanda riguardava il motivo per cui compilare con statico l'opzione non funzionava, la risposta a cui si collegava era nient'altro che un accenno a non usare il collegamento statico. Se non si discute perché è male, e richiede che l'OP usi il collegamento dinamico. La sua sfortuna è contrassegnata come la risposta corretta (la risposta che segue ha il doppio di voti ed è la risposta corretta alla domanda dell'OP) perché, sebbene la risposta corretta sia lì, è profondamente nascosta in mezzo ad un'opinione dogmatica.

La vera domanda è quali sono i pro ei contro del collegamento statico vs dinamico e quando si preferirebbe l'uno rispetto all'altro.

Dal punto di vista dello sviluppatore, il collegamento dinamico spesso velocizza notevolmente il ciclo di compilazione / collegamento / test.

Da un punto di vista della gestione dei pacchetti, prendi libGL, per esempio. Sono disponibili circa una dozzina di diverse implementazioni nel mio gestore pacchetti, alcune schede grafiche generiche e alcune specifiche del targeting. Se non fosse collegato dinamicamente, ci dovrebbero essere una dozzina di versioni di ogni programma che si collega a libGL, altrimenti dovresti escogitare un ulteriore livello di astrazione che non è efficiente come una chiamata di funzione.

Pensa a un problema di sicurezza in una libreria popolare come Qt. Con il collegamento dinamico, posso semplicemente aggiornare quel pacchetto, invece di dover identificare, ricompilare e distribuire ogni singolo pacchetto che collega in Qt.

Il collegamento statico può avere vantaggi nelle applicazioni closed source distribuite in modo indipendente, ma nella gestione dei pacchetti open source fa più male di quanto aiuti.

Le librerie condivise sono strongmente preferite dai maintainer di distribuzione di Linux fondamentalmente per la ragione # 2. È molto importante per loro che, ad esempio, quando qualcuno trova un bug di sicurezza in zlib , non Ricompilare ogni singolo programma che usa zlib --- non solo costerebbe loro più cicli di CPU per eseguire la ricompilazione, chiunque utilizzi la distribuzione dovrebbe quindi scaricare tutti questi programmi Nel frattempo, all'interno del set di pacchetti fornito da una distribuzione, l'inferno della dipendenza non è un problema, perché tutto è testato per funzionare con quel set di librerie.

Se stai costruendo software di terze parti che ha bisogno di librerie che non sono nella tua distribuzione, collegare staticamente quelle librerie potrebbe essere meno problematico dell'alternativa, e va bene.

L'altra cosa importante da sapere è che GNU libc e GCC libstdc++ hanno entrambi componenti che non funzionano in modo affidabile se la libreria è collegata staticamente. Il problema più comune è con dlopen , perché qualunque modulo caricato con dlopen è esso stesso dinamicamente collegato con libc.so.6 . Ciò significa che ora hai due copie della libreria C nello spazio degli indirizzi e l'ilarità si verifica quando non sono d'accordo su quale copia della struttura interna malloc dei dati (ad esempio) è autorevole. Diventa peggio: un sacco di funzioni che non sembrano avere nulla a che fare con dlopen , come gethostbyname e iconv , usare dlopen internamente (in modo che il loro comportamento sia configurabile in fase di runtime). Fortunatamente, l'ABI per libc e libstdc ++ è molto stabile, quindi è improbabile che incontri problemi collegandoli dinamicamente.

Sono d'accordo con l'ultimo punto di Mattnz: questa domanda è una domanda caricata. Suppone che il collegamento statico sia cattivo. Posso pensare a due ragioni per le quali questo non è il caso:

• Il collegamento statico è sicuro: se una libreria condivisa viene aggiornata in modo tale che un'applicazione utilizza quella nuova (forse la nuova sovrascrive la vecchia o la vecchia viene rimossa), può introdurre il rischio che la nuova versione si rompa l'applicazione. Questo è un cambio di codice che non rientra nell'ambito di un aggiornamento ufficiale dell'applicazione. Potrebbe non essere stato testato. Il collegamento statico aggira questo problema non condividendo le librerie esternamente. Ritengo che questo sia uno svantaggio delle librerie condivise a causa di questo rischio. Cosa succede se una nuova versione di una libreria condivisa introduce un nuovo bug che interrompe alcune vecchie applicazioni?

• Il collegamento statico assicura che un'applicazione sia più autonoma. Mentre le librerie condivise possono essere collocate insieme all'eseguibile principale, spesso vengono depositate in posizioni condivise. Le applicazioni collegate in modo statico sono più facili da garantire "portatili" nel senso di "non richiedere modifiche a file, directory o impostazioni di proprietà del sistema operativo" (si pensi a directory di Windows, registro, / etc).

Le librerie statiche e dinamiche hanno ciascuno i propri usi. Guardando una singola applicazione in ambito, otteniamo un'idea diversa su ciò che è necessario e ciò che non lo è.

Il collegamento statico semplifica drasticamente la distribuzione delle applicazioni. Non dover rilevare e gestire versioni diverse. Basta cuocere e distribuire.

L'ovvio vantaggio con le librerie dinamiche è la possibilità di applicare gli aggiornamenti in modo indipendente.

Questo è uno dei motivi per cui detesto Maven e altri simili costruttori di progetti di linking dinamico per java. Si aspettano che una singola versione di libreria sia disponibile in un determinato URL per sempre. Non capisco il problema che si verifica in 10 anni quando nessuno può compilare l'applicazione perché tutti i sorgenti e i vasi sono spariti.