Perché utilizzare il collegamento dinamico per le librerie meno popolari?

Question

Perché utilizzare il collegamento dinamico per le librerie meno popolari?

#1 da (9 voti)
#2 da (2 voti)

2

Conosco la differenza tra il collegamento statico e dinamico. So perché la nozione di biblioteca è importante. E so anche perché vorresti collegare qualcosa come OpenGL, API specifiche della piattaforma o OpenSSL in modo dinamico; molte applicazioni li usano (possibilmente contemporaneamente), quindi perché caricarli in memoria più di una volta?

Supponiamo però che io stia usando una piccola libreria C ++ che ho trovato su GitHub. È utile e (per quanto ne so io) privo di bug, ma lontano dal famoso o ampiamente usato, quindi le probabilità sono piuttosto buone che il mio programma sarà l'unico sul computer di un utente che usa tale libreria. Potrei collegarlo staticamente o dinamicamente; in tal caso, perché dovrei collegare dinamicamente detta libreria oscura?

Inoltre, diciamo che il mio progetto è open source.

libraries dll linking static-linking dynamic-linking

posta JesseTG 04.03.2016 - 21:47

fonte

2 risposte

Leggi altre domande sui tag libraries dll linking static-linking dynamic-linking

Significato di "istanza di un database" Gestione di epop che forniscono solo un prodotto spedibile alla fine

score 9 · Answer 1

Perché la licenza lo richiede per il tuo caso d'uso (per esempio, essendo LGPL LGPL e il tuo progetto proprietario).
Perché vuoi disaccoppiare la versione distribuita di app e lib.
Perché non sei assolutamente sicuro che la lib sia priva di errori.
Poiché le distribuzioni di destinazione forniscono (s) la lib attraverso il loro gestore pacchetti.
Poiché la lib è utilizzata da più di un binario e vuoi o devi minimizzare l'ingombro della tua app (pensa ai sistemi embedded).

E motivi per il collegamento statico:

Perché la licenza lo consente per il tuo caso d'uso.
Perché desideri eludere la seccatura di distribuire più di un file binario.
Perché sei sicuro che non ci sarà bisogno di scambiare la lib da parte di un aggiornamento dell'app.
Poiché la lib non viene fornita [nella versione richiesta, almeno e in modo affidabile] dalla gestione dei pacchetti del sistema di destinazione.
Perché non è (necessario) occuparsi dell'impronta.

E ci sono probabilmente altre ragioni. YMMV, e non c'è un proiettile d'argento.

score 2 · Answer 2

^{(Sto avendo un punto di vista orientato a Linux, non conosco Windows, ma la sua DLL potrebbe essere leggermente diversa dalle librerie dinamiche degli oggetti condivisi ELF di Linux)}

Una libreria condivisa è utile non appena si può avere più di un processo o un programma che lo utilizza: ad es. due programmi diversi che utilizzano la stessa libreria o forse anche due processi diversi che utilizzano la stessa libreria (in effetti, se quella libreria viene utilizzata da un solo programma, magari in esecuzione in diversi processi), non è necessario renderla una libreria).

Un altro motivo per avere una libreria condivisa è perché vuoi che sia aggiornabile indipendentemente dal / dai programma che lo usa. Questo è un motivo significativo, in particolare quando quella libreria è software libero (in particolare sotto licenza LGPL), ma i programmi che lo utilizzano sono proprietari.

^{(In parole povere, una LGPL libreria -ed è richiesta per essere collegato dinamicamente, in particolare se usato in applicazioni proprietarie, e il suo utente dovrebbe avere la libertà di aggiornare o migliorare facilmente la libreria LGPL-ed)}

Molto probabilmente, non potrei permettermi di non usare alcuna libreria statica sul mio sistema Linux (si noti che le librerie statiche sono importanti solo per costruire i binari, non sono rilevanti per eseguire questi binari linkati staticamente); ma non potrò evitare di utilizzare le librerie condivise (e poiché sono collegate dinamicamente , ho bisogno che eseguano i binari ).