La gestione delle dipendenze e delle librerie dinamiche non è un nuovo problema. Nel tuo scenario, l'uso di Docker non è correlato a questo problema poiché stai utilizzando Docker per raggruppare la tua toolchain di build (cioè i compilatori).
L'ambiente in cui viene eseguita la tua applicazione avrà bisogno di tutte le dipendenze. Tuttavia, ciò non significa che devi inquinare il sistema host.
Ad esempio, potrebbe essere possibile eseguire l'applicazione all'interno di un contenitore Docker che fornisce le dipendenze. Tuttavia, questo spesso non è adatto in quanto Docker preferisce strongmente immagini immutabili e può imporre una quantità non appropriata di isolamento.
Naturalmente esiste anche un'altra tecnologia di containerizzazione. Questo potrebbe essere appropriato se il tuo software richiede servizi / demoni appositamente configurati. Ma potresti non voler distribuire tramite contenitori, ad es. perché gli utenti dovrebbero installare il software di gestione dei contenitori, perché le immagini potrebbero richiedere un'eccessiva capacità di archiviazione o perché la distribuzione delle immagini dei contenitori rende difficile l'applicazione degli aggiornamenti di sicurezza alle dipendenze indipendentemente dal software.
L'uso del collegamento statico può essere un approccio molto conveniente, quando possibile. Nota che questo potrebbe non funzionare se le dipendenze non solo comprendono librerie ma anche altre risorse (caratteri, immagini, database, servizi esterni). Ciò potrebbe anche influire sulle licenze del software, in particolare se si dispone di dipendenze LGPL.
Potrebbe essere conveniente dichiarare tutte le dipendenze e utilizzare un sistema di gestione delle dipendenze esterno come APT per risolverle. Questo può essere molto user-friendly, ma può anche implicare dipendenze che non puoi controllare. Se non viene fornita una dipendenza, puoi impacchettarla in modo che si installi sotto /opt .
Non è necessario installare le dipendenze a livello globale. Se si configurano le dipendenze da installare con un prefisso locale (e impostare opportunamente LD_LIBRARY_PATH ), è possibile installare le dipendenze all'interno della directory del progetto. Puoi quindi distribuirli insieme alla tua app. Fondamentalmente, questo ti permette di avere facilmente più versioni delle tue dipendenze l'una dall'altra. (Re-) l'installazione delle dipendenze dovrebbe quindi far parte del normale processo di compilazione.
Queste strategie non sono esclusive ma possono essere mescolate e abbinate secondo necessità. Ad esempio, richiedendo che libstdc ++ in una versione adatta sia installata sul sistema host potrebbe essere OK, ma potresti voler collegare staticamente altre dipendenze. Oppure, se disponi di uno script di distribuzione in grado di installare localmente le dipendenze, è possibile utilizzarlo anche nel Dockerfile del contenitore di build.
Alla fine, quale di queste varianti è preferibile dipende da come il tuo software verrà installato e usato. Qualunque cosa è potenzialmente valida, purché tutto possa essere copiato.