Depende. Algo compilado para IA-32 (Intel 32-bit) pode rodar em AMD64, pois o Linux na Intel mantém a compatibilidade retroativa com aplicativos de 32 bits (com software adequado instalado). Aqui está o seu code compilado no sistema de 32 bits RedHat 7.3 (por volta de 2002, gcc versão 2.96) e então o binário copiado e executado em um sistema Centos 7.4 de 64 bits (por volta de 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
O antigo RedHat 7.3 ao Centos 7.4 (essencialmente RedHat Enterprise Linux 7.4) permanece na mesma família de "distribuição", então provavelmente terá melhor portabilidade do que passar de uma instalação aleatória do "Linux do zero" de 2002 para algum outro Linux aleatório distribuição em 2018.
Algo compilado para o amd64 não seria executado em versões de 32 bits do Linux (o hardware antigo não sabe sobre o novo hardware). Isso também é verdade para o novo software compilado em sistemas modernos que devem ser executados em coisas antigas antigas, como bibliotecas e Mesmo as chamadas do sistema podem não ser portáveis para trás, portanto podem exigir truques de compilação, ou obter um compilador antigo e assim por diante, ou possivelmente compilar no sistema antigo. (Esta é uma boa razão para manter as máquinas virtuais das antigas e antigas coisas por aí.)
A arquitetura é importante; O amd64 (ou IA-32) é muito diferente do ARM ou do MIPS, portanto, não se espera que o binário de um deles seja executado em outro. No nível da montagem, a seção main do seu código no IA-32 compila via gcc -S code.c para
main:
pushl %ebp
movl %esp,%ebp
movl $99,%eax
popl %ebp
ret
com o qual um sistema amd64 pode lidar (em um sistema Linux - o OpenBSD, ao contrário, em amd64 não suporta binários de 32 bits; a compatibilidade retroativa com antigos arcos dá espaço a invasores, por exemplo < CVE-2014-8866 e amigos). Enquanto isso, em um sistema MIPS big-endian main , em vez disso, compila para:
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
que um processador Intel não tem idéia do que fazer, e da mesma forma para a montagem Intel no MIPS.
Você poderia usar o QEMU ou algum outro emulador para executar código estrangeiro (talvez muito, muito lentamente).
No entanto! Seu código é muito simples, então terá menos problemas de portabilidade do que qualquer outra coisa; os programas tipicamente fazem uso de bibliotecas que mudaram com o tempo (glibc, openssl, ...); para aqueles que também podem precisar instalar versões mais antigas de várias bibliotecas (o RedHat, por exemplo, tipicamente coloca "compat" em algum lugar no nome do pacote para tal)
compat-glibc.x86_64 1:2.12-4.el7.centos
ou possivelmente se preocupar com alterações ABI (Application Binary Interface) para coisas antigas que usam glibc, ou alterações mais recentes devido a C ++ 11 ou outros releases C ++. Também é possível compilar a estática (aumentando bastante o tamanho binário no disco) para tentar evitar problemas de biblioteca, embora se algum antigo binário dependesse de a distribuição antiga do Linux estar compilando a maior parte da dinâmica (RedHat: yes) ou não. Por outro lado, coisas como patchelf podem reprojetar binários dinâmicos (ELF, mas provavelmente não a.out format) para usar outras bibliotecas.
No entanto! Ser capaz de executar um programa é uma coisa e realmente fazer algo útil com outro. Binários antigos de 32 bits da Intel podem ter problemas de segurança se dependerem de uma versão do OpenSSL que tenha algum problema de segurança horrível e não suportado, ou o programa pode não ser capaz de negociar com servidores web modernos (como o moderno os servidores rejeitam os protocolos e cifras antigos do programa antigo), ou a versão 1 do protocolo SSH não é mais suportada, ou ...