Collegamento statico con glibc e libstdC++

Sto scrivendo un'applicazione multipiattaforma che non è compatibile GNU GPL. Il problema principale che sto affrontando attualmente è che l'applicazione è collegata in modo dinamico con glibc e libstdC++, e quasi tutti i nuovi importanti aggiornamenti alle librerie non sono compatibili con le versioni precedenti. Quindi, si verificano crash casuali nella mia applicazione.Collegamento statico con glibc e libstdC++

Come soluzione temporanea, distribuisco i binari della mia applicazione compilati su diversi sistemi (con diverse versioni di runtime C/C++). Ma voglio fare a meno di questo. Quindi la mia domanda è, mantenendo le licenze e tutto ciò che ho in mente, posso collegarmi staticamente a glibc e libstdC++? Inoltre, questo causerà problemi con rtld?

fonte

2010-07-09 themoondothshine

I manutentori di glibc e libstdC++ fanno un ottimo lavoro per mantenere la compatibilità binaria al contrario. I rilasci importanti lo interrompono in base alla progettazione, ma questi non accadono troppo spesso. Probabilmente potresti risolvere il tuo problema costruendo i binari su un sistema non molto moderno, o usando alcuni strumenti LSB della Linux Foundation (vedi [qui] (http://www.linuxfoundation.org/collaborate/workgroups/lsb); gli strumenti sono gratuiti e sì, ho lavorato per loro, quindi sono di parte). –

Specificare l'opzione -static-libgcc nel linker causerebbe il collegamento a una versione statica della libreria C, se disponibile sul sistema. Altrimenti viene ignorato.

fonte

2011-01-15 19:25:42 themoondothshine

Hai anche bisogno di '-static-libstdC++', vedi [spiegazione] (http://www.trilithium.com/johan/2005/06/static-libstdc/) – ACyclic

Questa è una risposta * completamente * fasulla: '-statico -libgcc' ha * nulla * da fare con la libreria di sistema C. –

@themoondothshine dovresti * seriamente * risolvere questa risposta. Come sottolineato da Employ Russian 'libgcc! = Libc' (e questo indipendentemente dal fatto che abbia detto' libc == glibc' o no). 'libgcc' è una libreria runtime per supportare il codice generato dal compilatore. Leggi a riguardo [qui] (https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html). – 0xC0000022L

Non è necessario.

Copia le librerie originali collegate in una directory (../lib in questo esempio) nella cartella dell'applicazione.

come:

my_app_install_path

.bin
lib
documentazione

si rinomina app per qualcosa come app.bin. Sostituisci la tua app con un piccolo script di shell che imposta la variabile di ambiente LD_LIBRARY_PATH sul percorso della libreria (e concatena i precedenti contenuti LD_LIBRARY_PATH, se presenti). Ora ld dovrebbe essere in grado di trovare le librerie dinamiche a cui è collegato e non è necessario compilarle staticamente sul tuo eseguibile.

Ricordarsi di rispettare la LGPL aggiungendo l'attribuzione data alle librerie e indicando la documentazione in cui è possibile scaricare la sorgente.

fonte

2010-07-09 15:41:09

@Vitor: questa è la soluzione migliore, penso! Distribuisco comunque tutte le dipendenze di terze parti (ad esempio, zlib, libssh, openssl, yada yada ...) come librerie condivise con il pacchetto. L'unico requisito che impongo agli utenti è che abbiano il runtime standard C/C++ installato sul loro sistema. Se quello che dici funziona, ho già l'infrastruttura: l'app è fondamentalmente un servizio, quindi tutti gli script sono già installati !! – themoondothshine

@Vitor: Ho un'altra domanda: le versioni più recenti di RTLD saranno in grado di caricare dinamicamente tutte le librerie anche se sono compilate su sistemi molto vecchi? Cioè, non dovrei preoccuparmi di causare problemi di runtime se spedisco libstdC++ e glibc con la mia app, giusto? – themoondothshine

@themoondothshine Non ho mai avuto problemi con ld non riuscire a caricare tutte le librerie. Ho fatto questo negli ultimi 3 anni per spedire un pacchetto GIS closed-source su Linux. –

-1

Devo chiedermi che cosa diavolo stai facendo con le scarse funzioni della libreria?

Ho anche un software multipiattaforma. Funziona bene su sistemi Linux di ogni tipo. Costruisci con la versione più vecchia del software che vuoi supportare. Le librerie glibc e libstdC++ sono davvero molto compatibili con le versioni precedenti.

Ho costruito su CentOS 4 ed eseguito su RHEL 6 beta. Nessun problema. Posso costruire su Debian stabile ed eseguirlo su testing.

Ora, a volte ho problemi con alcune librerie se cerco di costruire, dico Debian vecchio e provate ad eseguirlo su CentOS 5.4. Questo di solito è dovuto alle scelte di configurazione della distribuzione che sono diverse, come la scelta di threading o non threading.

fonte

2010-07-09 15:57:53

Lascia che ti dica esattamente cosa è successo: ho usato per compilare i miei binari su CentOS 3.9 (con una vecchia versione di glibc - 2.3. Qualcosa). Ora, questo binario ha iniziato a bloccarsi su CentOS 5.4 e il core dump non puntava da nessuna parte. Alla fine sono andato dagli sviluppatori di CentOS e sono rimasti sorpresi dal fatto che l'applicazione funzionasse per quasi un mese senza incidenti su CentOS 5.4. Avevano suggerito di usare il sistema MockBuild di Fedora, ma ho deciso di andare a compilare in modo nativo su più piattaforme. Quindi quello che sto facendo con le funzioni della libreria non è tanto il problema quanto la retrocompatibilità. – themoondothshine

Non è vero. Recentemente abbiamo un cliente che utilizza il sistema basato sugli glibc-2.7 che ha causato l'esecuzione di tutti i programmi C++ contro glibc-2.1X, alcuni simboli mancanti in libstdC++. So.X (almeno iostream), oltre a CentOS è basato su RedHat, ed entrambi sono stati spediti con la libreria condivisa non così ultima (a differenza di altre distribuzioni), quindi non mi convince molto. – daisy

glibc è sotto licenza LGPL. Nella sezione 6. di LGPL 2.1, è possibile distribuire il programma collegato alla libreria purché si rispetti una delle cinque opzioni. Il primo consiste nel fornire il codice sorgente della libreria, insieme al codice oggetto (l'origine è facoltativa, non richiesta) del proprio programma, quindi può essere ricollegato alla libreria. In alternativa puoi fornire un'offerta scritta dello stesso. Il tuo codice non deve essere sotto la LGPL e non devi rilasciare la fonte.

libstdC++ è in GPL, ma con un major exception. In pratica, puoi semplicemente distribuire sotto la licenza di tua scelta senza fornire il codice sorgente o libstdC++. L'unica condizione è che tu compili normalmente, senza ad es. modifiche proprietarie o plugin a GCC.

IANAL, e dovresti considerare di consultarne uno se hai bisogno di una vera consulenza legale.

fonte

2010-07-09 16:00:58

Collegamento statico con glibc e libstdC++

risposta

Problemi correlati