Ça dépend. Quelque chose compilé pour IA-32 (Intel 32 bits) peut fonctionner sur amd64 car Linux sur Intel conserve la compatibilité descendante avec les applications 32 bits (avec un logiciel approprié installé). Voici votre code
compilation sur le système 32 bits RedHat 7.3 (circa 2002, version 2.96 gcc), puis le fichier binaire copié sur et exécuté sur un système Centos 7.4 64 bits (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
Ancient RedHat 7.3 à Centos 7.4 (essentiellement RedHat Enterprise Linux 7.4) reste dans la même famille de "distribution"; sa portabilité sera donc probablement meilleure que celle de passer d'une installation "Linux from scratch" aléatoire de 2002 à une autre distribution Linux aléatoire en 2018 .
Quelque chose compilé pour amd64 ne fonctionnerait pas avec les versions 32 bits de Linux uniquement (l'ancien matériel ne connaît pas le nouveau matériel). Ceci est également vrai pour les nouveaux logiciels compilés sur des systèmes modernes destinés à fonctionner sur des choses anciennes et anciennes, car les bibliothèques et même les appels système peuvent ne pas être portables en arrière, et peuvent donc nécessiter des astuces de compilation, ou l'obtention d'un ancien compilateur, etc. compiler sur l'ancien système. (C’est une bonne raison de conserver les machines virtuelles d’anciennes choses anciennes.)
L'architecture compte; amd64 (ou IA-32) est très différent d'ARM ou de MIPS, de sorte que le binaire de l'un de ceux-ci ne devrait pas s'exécuter sur un autre. Au niveau de l' Assemblée de la main
section de votre code sur IA-32 par compiles gcc -S code.c
à
main:
pushl %ebp
movl %esp,%ebp
movl $99,%eax
popl %ebp
ret
qu’un système amd64 peut traiter (sur un système Linux - OpenBSD, en revanche, sur amd64 ne prend pas en charge les fichiers binaires 32 bits; la compatibilité avec les anciens systèmes d’archives donne une certaine marge de manoeuvre aux attaquants, par exemple CVE-2014-8866 et ses amis). En attendant, un système MIPS big-endian main
compile à la place:
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
qui un processeur Intel n'aura aucune idée de quoi faire, et de même pour l'assemblage Intel sur MIPS.
Vous pouvez éventuellement utiliser QEMU ou un autre émulateur pour exécuter du code étranger (peut-être très, très lentement).
Pourtant! Votre code est très simple et aura donc moins de problèmes de portabilité qu'autre chose; les programmes utilisent généralement des bibliothèques qui ont changé au fil du temps (glibc, openssl, ...); pour ceux-là, il se peut que vous deviez également installer des versions plus anciennes de diverses bibliothèques (par exemple, RedHat place typiquement "compat" quelque part dans le nom du paquet)
compat-glibc.x86_64 1:2.12-4.el7.centos
ou éventuellement vous soucier des modifications ABI (Application Binary Interface) pour les anciennes choses qui utilisent glibc, ou plus récemment des modifications dues à C ++ 11 ou à d'autres versions C ++. On pourrait aussi compiler statique (en augmentant considérablement la taille du binaire sur le disque) pour éviter les problèmes de bibliothèque, bien que le comportement d’un ancien fichier binaire dépende du fait que l’ancienne distribution Linux compilait presque tout ce qui était dynamique (RedHat: oui) ou non. D’autre part, des éléments tels que les patchelf
binaires dynamiques de régénération (ELF, mais probablement pas de a.out
format) peuvent utiliser d’autres bibliothèques.
Pourtant! Pouvoir exécuter un programme est une chose et faire quelque chose d’utile avec elle en est une autre. Les anciens fichiers binaires Intel 32 bits peuvent poser des problèmes de sécurité s’ils dépendent d’une version d’OpenSSL comportant un problème de sécurité horrible et non rétroporté. Sinon, le programme risque de ne pas pouvoir négocier du tout avec les serveurs Web modernes (comme le les serveurs rejettent les anciens protocoles et les chiffrements de l'ancien programme), ou la version 1 du protocole SSH n'est plus prise en charge, ou ...