bash: ./program: impossibile eseguire il file binario: errore formato Exec

Sto cercando di eseguire un programma, ma si verifica un errore come questo:

bash: ./program: cannot execute binary file: Exec format error

Il risultato è file programstato:

program: ELF-32-bit LSB executable, ARM, EABI4 version 1 (SYSV), dynamically linked(uses share libs), for GNU/LINUX 2.6.16, not stripped

Come posso correggere questo errore?

Sto usando Ubuntu 14.04.2 (amd64) con VMware. Ho anche provato con Ubuntu i386, ma il risultato è stato lo stesso.

Stai cercando di eseguire un eseguibile compilato per un'architettura ARM su un'architettura x86-64, che è molto simile a chiedere al tuo processore che parla solo inglese di prendere indicazioni in cinese.

Se devi eseguire quel file eseguibile hai due possibilità:

1. Ottieni una versione x86-64 dell'eseguibile (con qualsiasi mezzo; se non riesci a ottenere una versione x86-64 dell'eseguibile ma sei in grado di ottenere il suo codice sorgente, puoi provare a ricompilarlo sulla macchina virtuale );

2. Installa Ubuntu Server per ARM al posto di Ubuntu 14.04.2 (amd64). Ciò richiede una macchina fisica in esecuzione su un'architettura ARM o un software di virtualizzazione in grado di emularla.

Ciò può verificarsi anche se si tenta di eseguire un eseguibile x86-64 su una piattaforma a 32 bit.

In un'istanza specifica, ho scaricato Visual Studio Code e ho provato a eseguirlo sulla mia installazione di Ubuntu, ma non mi ero reso conto di aver installato Ubuntu a 32 bit in questa VM. Ho riscontrato questo errore, ma dopo aver scaricato la versione a 32 bit, è stato eseguito senza problemi.

È spesso possibile eseguire un'immagine eseguibile ARM su un sistema amd64 se si installano i pacchetti binfmt-support , qemu e qemu-user-static :

sudo apt install binfmt-support qemu qemu-user-static

qemueseguirà quindi l'emulazione syscall quando si esegue l'eseguibile. Funziona con la maggior parte dei binari ARM ma ce ne sono alcuni che potrebbero non funzionare correttamente.

Tale errore può verificarsi se sono vere tutte le seguenti condizioni:

• L'eseguibile non è un file ma un collegamento
• Lo esegui all'interno della VM
• Il file si trova nella cartella condivisa
• Il tuo host è Windows.

Se hai quel file, diciamo, nell'archivio - prova a decomprimerlo all'interno della VM, in qualche directory all'interno del disco virtuale, non nella cartella mappata sul disco rigido del tuo computer host, ad esempio /myNewDir/

È necessario compilare il file utilizzando un'architettura CPU appropriata (ad esempio x86) e copiare il file .exe sul proprio computer linux. Quindi puoi installare mono sul tuo computer Linux ed emettere il seguente comando:

mono myprogram.exe

Se javasul sistema è installato più di uno , ciò potrebbe accadere e non essere impostato come predefinito. Su Ubuntu14.04 LTS ho potuto risolverlo eseguendo il seguente e scegliendo il javanecessario.

sudo update-alternatives --config java
[sudo] password for user: 
update-alternatives: warning: /etc/alternatives/java has been changed (manually or by a script); switching to manual updates only
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      auto mode
  1            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      manual mode
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1069      manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java to provide /usr/bin/java (java) in manual mode

Ho scelto 2 e impostato openjdk-8come predefinito. Che non ha mostrato il Exec format error.

Questo può accadere anche se il binario usa un'implementazione libc che non è libc, come musl. Al giorno d'oggi questo problema specifico si riscontra molto probabilmente quando si tenta di eseguire un binario con libc in un contenitore Docker con un'immagine basata su alpine. Non c'è nulla che possa essere fatto al binario stesso per supportare entrambi gli ambienti, perché l'implementazione di libc deve sempre essere collegata staticamente, cioè incorporata direttamente nel binario, per ragioni.