Il mio binario linux funzionerà su tutte le distro?


24

Ho trovato un buon IDE sostitutivo per Delphi chiamato Lazzaro. Ma non ho una domanda per i programmatori.

Il binario Linux collegato staticamente funzionerà su tutte le distribuzioni Linux? Cioè non importa su quale distribuzione Linux l'ho costruita e funzionerà su Debian / ArchLinux / Ubuntu / OpenSUSE / ... qualunque cosa?

Come risultato delle mie scoperte, conta davvero solo 32 bit contro 64 bit? Voglio essere sicuro prima di pubblicare.



Puoi essere più specifico su quale tipo di librerie prevedi di collegare il tuo programma? Alcune librerie hanno dipendenze nascoste (file di dati, sottosistemi dinamici) o ipotesi altrimenti implicite sul sistema su cui sono in esecuzione.
Thomas Erker,

Risposte:


29

Questa risposta è stata scritta per la prima volta per la domanda più generale "il mio binario funzionerà su tutte le distro", ma si rivolge ai binari collegati staticamente nella seconda metà.


Per tutto ciò che è più complesso di un mondo ciao staticamente collegato, la risposta è probabilmente no .
Senza testarlo sulla distribuzione X, supponiamo che la risposta sia negativa per X.

Se vuoi spedire il tuo software in forma binaria, limitati a

  • alcune distribuzioni popolari per il campo di utilizzo del software (desktop, server, incorporato, ...)

  • le ultime una o due versioni di ciascuna

Altrimenti si finisce con centinaia di distribuzioni di tutte le dimensioni, versioni ed età (la distribuzione di dieci anni è ancora in uso e supportata).

Prova per quelli. Solo qualche puntatore su cosa può (e andrà) diversamente andare diversamente:

  • Il pacchetto di uno strumento / libreria necessario è denominato in modo diverso tra le distribuzioni e anche le versioni della stessa distribuzione

  • Le librerie necessarie sono troppo nuove o troppo vecchie (versione errata). Non dare per scontato solo perché il tuo programma può collegarsi, si collega con la libreria giusta.

  • La stessa libreria (file su disco) è denominata diversamente su diverse distribuzioni, rendendo impossibile il collegamento

  • 32 bit su 64 bit: l'ambiente a 32 bit potrebbe non essere installato o alcune librerie a 32 bit non essenziali vengono spostate in un pacchetto aggiuntivo oltre all'ambiente 32on64, quindi si ha una dipendenza aggiuntiva solo per questo caso.

  • Shell: non dare per scontato la tua versione di Bash. Non dare per scontato nemmeno Bash.

  • Strumenti: non dare per scontato che esista qualche strumento da riga di comando non POSIX.

  • Strumenti: non dare per scontato che lo strumento riconosca un'opzione solo perché la versione GNU della tua distribuzione lo fa.

  • Interfacce del kernel: non assumere l'esistenza o la struttura dei file /procsolo perché esistono / hanno la struttura sul tuo computer

  • Java: sei davvero sicuro che il tuo programma gira su IBM JRE come fornito con SLES senza testarlo?

Bonus:

  • Set di istruzioni: il file binario compilato sulla macchina non funziona su hardware precedente.

Il collegamento statico (o: raggruppando tutte le librerie di cui hai bisogno con il tuo software) è una soluzione? Anche se funziona tecnicamente, i costi associati potrebbero essere troppo elevati. Quindi, sfortunatamente, la risposta è probabilmente no.

  • Sicurezza: si sposta la responsabilità di aggiornare le librerie dall'utente del proprio software a se stessi.

  • Dimensioni e complessità: solo per divertimento prova a creare un programma GUI collegato staticamente.

  • Interoperabilità: se il tuo software è un "plug-in" di qualsiasi tipo, dipendi dal software che ti chiama.

  • Progettazione della libreria: se colleghi staticamente il tuo programma a GNU libc e usi i servizi dei nomi ( getpwnam()ecc.), Finisci per collegarti dinamicamente al NSS (switch del servizio dei nomi) di libc.

  • Progettazione della libreria: la libreria a cui colleghi staticamente il tuo programma utilizza file di dati o altre risorse (come fusi orari o locali).


Per tutti i motivi sopra menzionati, i test sono essenziali.

  • Acquisisci familiarità con KVM o altre tecniche di virtualizzazione e disponi di una macchina virtuale di ogni distribuzione che prevedi di supportare. Testa il tuo software su ogni VM.

  • Utilizzare installazioni minime di tali distribuzioni.

  • Creare una VM con un set di istruzioni limitato (ad es. Senza SSE 4).

  • Collegati staticamente o solo in bundle: controlla i tuoi binari con lddper vedere se sono realmente staticamente collegati / usa solo le tue librerie raggruppate.

  • Solo staticamente collegato o raggruppato: crea una directory vuota e copia il tuo software in essa. chrootin quella directory ed esegui il tuo software.


Questa è una risposta abbastanza completa +1
sirlark

2
Shell: In particolare, Debian non usa bash e dal momento che ha mitigato notevolmente la vulnerabilità di Shellshock sui sistemi Debian, non riesco a immaginare che cambi nell'immediato futuro.
Kevin,

1
Inoltre, se si desidera spedire file binari, collegarli staticamente .
user253751

Perché "set di istruzioni" è chiamato "bonus"? Se distribuisci in formato binario, devi davvero considerare quali ISA dovrai compilare. Potrebbe non interessarti agli utenti di m68k, ma è difficile ignorare almeno ARM, IA32 e X86_64.
Toby Speight,

@TobySpeight Pensa a SSE4 e simili. Potrebbe morderti solo se usi l'assemblatore.
Thomas Erker,

9

La risposta è che dipende. , ma nella maggior parte dei casi sì, purché nel sistema operativo siano installate le librerie necessarie.

In genere, la maggior parte delle distro, come quelle che hai citato, hanno i loro strumenti di gestione dei pacchetti che installano la versione gestita della comunità dell'applicazione. Questo si occupa di tutti i pacchetti prerequisiti necessari per l'applicazione. Se lo stai installando senza un gestore di pacchetti, spetta a te assicurarti che tutti i pacchetti e le librerie necessari siano installati sul sistema operativo. È una buona idea includere un elenco di queste applicazioni prerequisito nella documentazione.


2

Prima la risposta scadente: dipende

Se rilasci binari, supponi che la risposta sia "no" a meno che tu non stia distribuendo tutte le librerie che mai coinvolge con esso (da zero, il che è fastidioso a meno che tu non stia fornendo un sistema davvero enorme che si regge da solo ) o collegano staticamente l'equivalente.

... ma maghi e soldi, e maghi soldi ...

IBM ha alcuni installatori "Unixish generali" che mi hanno scioccato lavorando ovunque io li abbia provati: diversi Linuce di diverse generazioni di kernel, OpenSolaris (o come si chiama ora), Solaris e BSD. Ma sono enormi. E le cose che forniscono sono ugualmente enormi. Nessun piccolo programma di auto da corsa viene pubblicato in questo modo, ma solo le grandi cose di tipo aziendale che ti aspetteresti da IBM.

Per quanto riguarda il semplice restare su Linux, ma funziona bene su gran parte di Linuxdom, questo sembra essere possibile in forma binaria, come evidenziato dalla varietà di programmi di installazione binari di tipo "per Linux (generale)" che vedrai da alcuni fornitori. Diverse chat, browser, giochi, meta-installer, ecc. Sono pubblicati in questo modo, ma sempre da grandi venditori che possono passare il tempo per farlo bene. È un po 'sorprendente che possano dire "per Linux" ed essere generalmente fiduciosi che funzionerà, ma questo sembra essere il caso.

Ma...

Distribuisco il mio software come sorgente con un'utilità di creazione. Faccio questo in C, Erlang, Python, Guile, ecc. Questo mi dà molta più flessibilità sul fatto che funzionerà o meno, ed è molto più facile scrivere un buildscript che assicuri che esistano le cose giuste al momento della compilazione rispetto a assicurarsi che tutto sia a posto in fase di esecuzione. Una volta che esiste, è banale scrivere un auto-aggiornamento per il tuo programma se distribuisci il sorgente: il sorgente è di solito molto più piccolo di un binario che include tutti i deps e altre follia. Usando questo metodo non ho avuto molti problemi a distribuire in modo affidabile su Unices (e talvolta su Windows, ma è un po 'più di un lavoro ingrato).

Abbastanza bambino, armati!

Quando stai diventando serio, come srsly srs, per adattarti senza problemi al mondo Linux, distribuisci sorgenti C o ti rivolgi a un ambiente completamente gestito per un linguaggio deliziosamente hacking che è già pre-costruito. Se stai scrivendo codice Python, ad esempio, puoi controllare le versioni e sapere con quale versione di CPython funziona la tua, e generalmente ti aspetti che esista una versione compatibile su un dato Linux (e questo è molto più facile da controllare rispetto a una vasta gamma di librerie C / versioni che potresti utilizzare). Erlang, Guile, Python, Perl, CL, ecc. Sono tutti molto obiettivi facili per questo tipo di distribuzione, e molti di essi hanno un repository centrale come CPAN o pip (o qualsiasi altra cosa) in cui gli utenti possono eseguire un comando per estrarre da soli la fonte firmata quando lo desiderano e sanno che le cose generalmente funzioneranno come previsto .

[Addendum: 1. Anche Haskell può generalmente farlo tramite Cabal , anche se sarei cauto nel farlo in un ambiente di produzione. 2. Esistono diverse strategie di distribuzione "a rilascio" con Erlang che garantiscono che il codice disponga di un ambiente completo. 3. Python fa un passo avanti con gli ambienti virtuali; non tutti i tempi di esecuzione ti aiutano tanto.]

Quest'ultimo aspetto degli ambienti gestiti su Linux è davvero fantastico . E, come bonus, ti consente di definire dipendenze molto più generali, di risolverle automaticamente senza alcuno sforzo aggiuntivo da parte tua, non richiede la scrittura di un pacchetto per distribuzione e puoi smettere di preoccuparti se un sistema è 32 o 64 bit (generalmente, comunque).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.