« exec format error » et « cannot execute binary file » : incompatibilités d'architecture et de shebang

Ce que c'est

Il s'agit de l'erreur ENOEXEC renvoyée par execve(2) dans le noyau ; sa page de manuel la décrit comme un exécutable dont le format est soit reconnu mais non pris en charge, soit absent. Bash la signale par cannot execute binary file: Exec format error, les versions récentes de Docker/runc par exec /usr/local/bin/app: exec format error (versions plus anciennes : standard_init_linux.go:NNN: exec user process caused: exec format error), et Python par OSError: [Errno 8] Exec format error. Deux causes produisent cette erreur, et une troisième, apparentée, échoue avec un message différent :

• Incompatibilité d'architecture : un binaire ELF compilé pour une architecture de processeur (arm64, par exemple) est exécuté sur un matériel d'une autre architecture (amd64), sans émulateur enregistré via binfmt_misc.
• Shebang absent ou mal formé : un script n'a pas de première ligne #!interpreter, ou quelque chose la précède (par exemple une marque d'ordre des octets UTF-8). Un shell interactif masque ce cas en exécutant lui-même le fichier comme un script shell ; tout ce qui appelle execve directement (point d'entrée de conteneur, appel de sous-processus) reçoit ENOEXEC.
• Fins de ligne CRLF dans le shebang : le retour chariot final fait partie du chemin de l'interpréteur, le noyau renvoie alors ENOENT, et le message dépend du shell : bash 5.1 et antérieurs (ainsi que 5.3) affichent /bin/bash^M: bad interpreter: No such file or directory, bash 5.2 affiche cannot execute: required file not found, et une ligne #!/usr/bin/env bash donne /usr/bin/env: 'bash\r': No such file or directory.

Pourquoi c'est important

Les trois cas sont fréquents dans le travail multiplateforme : récupération d'une image de conteneur construite pour une autre architecture que celle de l'hôte, copie de scripts d'un système d'exploitation à l'autre, ou génération d'un script avec un outil qui écrit du CRLF par défaut. Le message, très laconique, n'indique pas quelle cause s'applique.

Comment l'appliquer

• Commencer par le diagnostic : file ./target indique soit l'architecture ELF ("ELF 64-bit LSB executable, ARM aarch64"), soit, pour un script, la présence de terminateurs de ligne CRLF. Comparer l'architecture d'un ELF avec uname -m sur l'hôte, ou avec la plateforme cible d'un conteneur au moyen de docker image inspect <image> --format '{{.Architecture}}'.
• Corrections, de la moins à la plus invasive :
  1. Shebang en CRLF : supprimer les retours chariot, par exemple avec sed -i 's/\r$//' script.sh ou dos2unix script.sh.
  2. Shebang absent ou corrompu : ajouter une première ligne correcte, par exemple #!/usr/bin/env bash.
  3. Incompatibilité d'architecture dans les conteneurs : demander explicitement la bonne plateforme avec docker run --platform linux/amd64 ..., ou construire pour plusieurs plateformes avec docker buildx build --platform linux/amd64,linux/arm64 ..., comme le décrit la documentation de Docker sur les builds multiplateformes.
  4. Recompiler le binaire nativement pour l'architecture cible plutôt que de compter sur l'émulation, surtout pour tout ce qui est sensible aux performances.
• Ce qui n'est pas une correction : chmod +x seul ne change rien à une incompatibilité de format ou d'architecture. Il vaut toutefois la peine de l'écarter séparément, car l'absence du bit d'exécution produit un autre message ("Permission denied").

Pièges

• Supposer que le message signifie toujours « mauvaise architecture » et recompiler inutilement alors que la vraie cause est un shebang en CRLF.
• Tester une image arm64 sur amd64 sous émulation QEMU et en conclure que tout va bien : l'émulation est lente et a ses propres bogues, si bien qu'un test réussi ne prouve pas que l'image se comportera de la même façon sur un vrai matériel arm64.