Creazione di file binari di Linux per più piattaforme

Question

Aiutami a regolare un punteggio.

Ho un software scritto in C++ che è pensato per funzionare su quante più distribuzioni Linux possibili e ho bisogno di capire una strategia che sia efficace. Sto cercando di spedire i binari in questo caso non il codice sorgente (potrebbe essere utile sapere). È già un prodotto commerciale e ho problemi di proprietà intellettuale che mi impediscono di aprire il prodotto ma significa anche che devo affrontare una miriade di problemi GPL.

L'attuale linea di ragionamento è stata quella di scegliere un minimo comune denominatore e costruire tutto da quello. Questo ha due importanti implicazioni che trovo controproducenti.

1. Il supporto C++ nelle vecchie versioni di GCC manca di alcune funzionalità C++ più moderne.
2. Il minimo comune denominatore comporta Red Hat Enterprise Linux 4 (RHEL4)

io sicuramente non ho bisogno la funzione dell'intero C++ 11 set ma mi piacerebbe portare sostegno alla ++ C fino a quel di Visual C++ 2010. Sto esaminando l'idea di utilizzare Clang/libC++ invece di GCC/libstdC++ dove possibile.

RHEL4 non sembra avere un esteso supporto multipiattaforma per la compilazione di applicazioni C++, ho più informazioni sulla stabilità di ABI su diverse versioni di Linux, ma temo che RHEL4 sia più un problema che altro. Cercare di costruire per tutte le distribuzioni basate su pochi non è una strategia praticabile.

Sono sotto il presupposto che la compilazione di software per diverse distribuzioni di Linux sia meglio realizzata compilando il software per la piattaforma di destinazione con strumenti sulla piattaforma di destinazione. Attualmente sto operando anche nel presupposto che ti imbatterai in vasti problemi di portabilità su piattaforme cross-line se non lo accetti. Per non parlare delle numerose librerie con cui è possibile o impossibile collegarsi a causa dell'instabilità di C++ ABI su piattaforme/distribuzioni.

Ma potrei sbagliarmi, mi piacerebbe sentire dalle persone che si occupano di questo su base regolare. Cosa funzionerà e perché? o, soprattutto, cosa non funzionerà?

Answer 1

si può tentare di concentrarsi su un poche piattaforme principali piuttosto che singole distribuzioni. Ciò che intendo è costruire su quelle che io chiamo "distro fondazionali" (Debian e RedHat) e sperare per il meglio sugli altri.

Molto probabilmente, i binari di Debian (che sono collegati staticamente) funzioneranno bene su Ubuntu e Mint e altre distribuzioni derivate da Debian. I binari RedHat funzioneranno probabilmente su Centos, Scientific Linux e SuSE Linux. Se ti interessano le distro meno popolari (Supponi che molti clienti eseguano un Linux non comune), né il tuo eseguibile Debian o RedHat lavora su di esse o può essere fatto funzionare in qualche modo, quindi imposta una VM di quella distribuzione e crea un eseguibile specificamente per quel sapore.

Ho adottato questo approccio in passato e ha funzionato bene.

Answer 2

Il modo migliore per fare in modo che il software sia open source (free software) (ad esempio licenza GPLv3 +), se il software è abbastanza interessante verrà distribuito nelle distribuzioni (dal responsabile della distribuzione).

Si desidera sempre fornire pacchetti di distribuzione (ad esempio file .deb per Ubuntu o Debian) perché questi sono i più facili da installare.

Se si vuole ancora rendere il software proprietario (ma chiedetevi se si sarà in grado di vendere, o addirittura distribuire gratis, successo il software), si potrebbe procedere come segue:

• compilare un compilatore GCC recente (ad es. 4.8) abilitando uno stdc statico ++ & un libgcc statico (la maggior parte della distribuzione fornita da GCC non lo fa).

• collegare il programma in modo statico (ma potrebbe non essere possibile farlo, ad esempio per le funzioni correlate a /etc/nsswitch.conf, incluso getaddrinfo e relativi servizi DNS).

Anche collegando tutti i C++ cose relative staticamente ancora dipendere da libc.so.6 e allora si può avere alcuni problemi di controllo delle versioni LIBC (quindi un binario compilato per una versione libc 2.17 non sarà sempre eseguito con un libc 2.16 o vice versa). Notate anche che GNU libc di solito è legato ad alcune versioni del kernel (non potete usare una libc recente su un kernel piuttosto vecchio). Si potrebbe prendere in considerazione alcune alternative come libc MUSL libc

BTW, di solito si può usare un po 'di chroot ambiente di destinazione -ed (in cui si potrebbe installare qualche altra distribuzione, ad esempio. Con debootstrap)

Answer 3

Se qualcuno è curioso, abbiamo risolto il problema costruendo una toolchain GCC 4.8 su un RHEL 4.8 dist che ha continuato a essere il nostro agente di costruzione.

Il punto cruciale è delineato here. Il problema era un po 'più semplice poiché non abbiamo bisogno di un cross-compiler completamente funzionale. Solo una toolchain GCC 4.8 sull'host di destinazione.

L'interoperabilità era ancora un problema perché questa vecchia versione di Linux non aveva praticamente alcun supporto per SMB e/o altre tecnologie. Abbiamo finito con uno script Bash che metteva gli output build in un server FTP e questo ha funzionato abbastanza bene. Ha risolto i principali dolori.