Un eseguibile Linux compilato su un "sapore" di Linux verrà eseguito su un altro?

L'eseguibile di un programma piccolo, estremamente semplice, come quello mostrato di seguito, compilato su una versione di Linux, funzionerà su una versione diversa? O dovrebbe essere ricompilato?

L'architettura della macchina è importante in un caso come questo?

int main()
{
  return (99);
}

Dipende. Qualcosa compilato per IA-32 (Intel a 32 bit) potrebbe essere eseguito su amd64 poiché Linux su Intel mantiene la retrocompatibilità con le applicazioni a 32 bit (con software adeguato installato). Ecco il tuo codecompilato sul sistema RedHat 7.3 a 32 bit (circa 2002, gcc versione 2.96) e poi il binario copiato su ed eseguito su un sistema Centos 7.4 a 64 bit (circa 2017):

-bash-4.2$ file code
code: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
-bash-4.2$ ./code
-bash: ./code: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
-bash-4.2$ sudo yum -y install glibc.i686
...
-bash-4.2$ ./code ; echo $?
99

L'antica RedHat da 7.3 a Centos 7.4 (essenzialmente RedHat Enterprise Linux 7.4) si trova nella stessa famiglia "distributiva", quindi probabilmente avrà una portabilità migliore rispetto a passare da un'installazione casuale "Linux da zero" dal 2002 ad un'altra distribuzione Linux casuale nel 2018 .

Qualcosa compilato per amd64 non funzionerebbe solo su versioni a 32 bit di Linux (il vecchio hardware non è a conoscenza del nuovo hardware). Ciò vale anche per i nuovi software compilati su sistemi moderni destinati a essere eseguiti su vecchie cose antiche, poiché le librerie e persino le chiamate di sistema potrebbero non essere portatili all'indietro, quindi potrebbero richiedere trucchi di compilazione o ottenere un vecchio compilatore e così via, o forse invece compilando sul vecchio sistema. (Questa è una buona ragione per tenere in giro macchine virtuali di vecchie cose antiche.)

L'architettura è importante; amd64 (o IA-32) è molto diverso da ARM o MIPS quindi il binario di uno di questi non dovrebbe funzionare su un altro. A livello di assembly la mainsezione del codice su IA-32 viene compilata tramite gcc -S code.ca

main:
    pushl %ebp
    movl %esp,%ebp
    movl $99,%eax
    popl %ebp
    ret

con cui un sistema amd64 è in grado di gestire (su un sistema Linux - OpenBSD, al contrario, su amd64 non supporta i binari a 32 bit; la retrocompatibilità con i vecchi archi lascia spazio agli aggressori, ad esempio CVE-2014-8866 e amici). Nel frattempo su un sistema MIPS big-endian main invece compila per:

main:
        .frame  $fp,8,$31
        .mask   0x40000000,-4
        .fmask  0x00000000,0
        .set    noreorder
        .set    nomacro
        addiu   $sp,$sp,-8
        sw      $fp,4($sp)
        move    $fp,$sp
        li      $2,99
        move    $sp,$fp
        lw      $fp,4($sp)
        addiu   $sp,$sp,8
        j       $31
        nop

che un processore Intel non avrà idea di cosa fare e allo stesso modo per l'assemblaggio Intel su MIPS.

È possibile utilizzare QEMU o un altro emulatore per eseguire il codice esterno (forse molto, molto lentamente).

Però! Il tuo codice è un codice molto semplice, quindi avrà meno problemi di portabilità rispetto a qualsiasi altra cosa; i programmi in genere fanno uso di librerie che sono cambiate nel tempo (glibc, openssl, ...); per quelli potrebbe anche essere necessario installare versioni precedenti di varie librerie (ad esempio RedHat generalmente inserisce "compat" nel nome del pacchetto)

compat-glibc.x86_64                     1:2.12-4.el7.centos

o forse preoccuparsi delle modifiche ABI (Application Binary Interface) per cose vecchie che usano glibc, o più recenti modifiche dovute a C ++ 11 o altre versioni di C ++. Si potrebbe anche compilare statico (aumentando notevolmente la dimensione binaria su disco) per cercare di evitare problemi con la libreria, anche se il fatto che qualche vecchio binario lo abbia fatto dipende dal fatto che la vecchia distribuzione Linux stia compilando quasi tutto dinamico (RedHat: yes) o no. D'altra parte, cose come patchelfpossono riattivare i binari dinamici (ELF, ma probabilmente non a.outformattarli) per usare altre librerie.

Però! Essere in grado di eseguire un programma è una cosa, e in realtà fare qualcosa di utile con un'altra. I vecchi binari Intel a 32 bit possono avere problemi di sicurezza se dipendono da una versione di OpenSSL che ha in sé qualche problema di sicurezza orribile e non backport, oppure il programma potrebbe non essere in grado di negoziare affatto con i moderni server Web (come i moderni i server rifiutano i vecchi protocolli e le cifre del vecchio programma), oppure il protocollo SSH versione 1 non è più supportato, oppure ...

In breve: se stai portando un binario compilato da un host a un altro usando la stessa (o compatibile) architettura , potresti andare perfettamente in un'altra distribuzione . Tuttavia, con l'aumentare della complessità del codice, aumenta la probabilità di essere collegati a una libreria non installata; installato in un'altra posizione; o installato in una versione diversa, aumenta. Prendendo ad esempio il tuo codice, per il quale lddriporta le seguenti dipendenze quando compilato gcc -o exit-test exit-test.csu un host Ubuntu Linux (derivato da Debian):

$ ldd exit-test
    linux-gate.so.1 =>  (0xb7748000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb757b000)
    /lib/ld-linux.so.2 (0x8005a000)

Ovviamente questo binario non funzionerà se lo lancio su, diciamo, su un Mac ( ./exit-test: cannot execute binary file: Exec format error). Proviamo a spostarlo in una scatola RHEL:

$ ./exit-test
-bash: ./exit-test: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Oh caro. Perché potrebbe essere?

$ ls /lib/ld-l* # reference the `ldd` output above
ls: cannot access /lib/ld-l*: No such file or directory

Anche per questo caso d'uso, il forklift è fallito a causa della mancanza di librerie condivise.

Tuttavia, se lo compilo gcc -static exit-test-static exit-test.c, il porting sul sistema senza le librerie funziona bene. A spese, ovviamente, dello spazio su disco:

$ ls -l ./exit-test{,-static}
-rwxr-xr-x  1 username  groupname    7312 Jan 29 14:18 ./exit-test
-rwxr-xr-x  1 username  groupname  728228 Jan 29 14:27 ./exit-test-static

Un'altra soluzione praticabile sarebbe quella di installare le librerie necessarie sul nuovo host.

Come per molte cose nell'universo U&L, questo è un gatto con molte pelli, due delle quali sono descritte sopra.

In aggiunta alle eccellenti risposte @thrig e @DopeGhoti: i sistemi operativi Unix o Unix, incluso Linux, erano tradizionalmente sempre progettati e allineati più per la portabilità del codice sorgente che per i binari.

Se non si ha nulla di specifico sull'hardware o si tratta di un semplice sorgente come nell'esempio, è possibile spostarlo senza alcun problema tra praticamente qualsiasi versione di Linux o architettura come codice sorgente purché i server di destinazione abbiano i pacchetti di sviluppo C installati , le librerie necessarie e le librerie di sviluppo corrispondenti installate.

Per quanto riguarda il porting di codice più avanzato da versioni precedenti di Linux distanti nel tempo, o programmi più specifici come moduli del kernel per diverse versioni del kernel, potrebbe essere necessario adattare e modificare il codice sorgente per tenere conto di librerie / API / ABI obsolete.

Per impostazione predefinita , quasi sicuramente incontrerai problemi con le librerie esterne. Alcune delle altre risposte approfondiscono questi problemi, quindi non duplicherò il loro lavoro.

È possibile , tuttavia, compilare molti programmi - anche quelli non banali - per essere portabile tra i sistemi Linux. La chiave è un toolkit chiamato Linux Standard Base . Il LSB è stato progettato per creare solo questi tipi di applicazioni portatili. Compilare un'applicazione per LSB v5.0 e verrà eseguita su qualsiasi altro ambiente Linux (della stessa architettura) che implementa LSB v5.0. Alcune distro Linux sono conformi a LSB e altre includono toolkit / librerie LSB come pacchetto installabile. Se costruisci la tua applicazione usando gli strumenti LSB (come il lsbccwrapper per gcc) e ti colleghi alla versione LSB delle librerie, creerai un'applicazione portatile.

Può essere.

Le cose che tendono a romperlo includono.

1. Diverse architetture. Ovviamente architetture totalmente diverse non funzioneranno (a meno che tu non abbia qualcosa come la modalità utente qemu con binfmt_misc ma non è una configurazione normale). i binari x86 possono funzionare su amd64 ma solo se sono disponibili le librerie a 32 bit richieste.
2. Versioni della libreria. Se la sovversione è sbagliata, non troverà affatto la libreria. Se la sovversione è la stessa ma il binario è costruito su una versione più recente della libreria rispetto a quella in esecuzione, potrebbe non riuscire a caricarsi a causa di nuovi simboli o nuove versioni di simboli. In particolare, glibc è un grande utilizzatore del versioning dei simboli, quindi è molto probabile che i binari creati con un nuovo glibc falliscano con un vecchio glibc.

Se si evita di utilizzare librerie che cambiano rapidamente, evitare i cambiamenti dell'architettura e basarsi sulla distro più vecchia che si desidera indirizzare, si hanno buone probabilità di far funzionare un binario su molte distro.

Oltre ad alcune delle cose menzionate in precedenza, sono state apportate alcune modifiche al formato del file eseguibile. Per la maggior parte, Linux usa ELF, ma le versioni precedenti usavano a.out o COFF.

L'inizio di un wikihole:

https://en.wikipedia.org/wiki/Comparison_of_executable_file_formats

Potrebbe esserci un modo per ottenere versioni precedenti per eseguire formati più recenti, ma personalmente non l'ho mai esaminato.