Linuxの1つの「フレーバー」でコンパイルされたLinux実行可能ファイルは、別の実行可能ファイルで実行されますか？

Linuxの1つのフレーバーでコンパイルされた、以下に示すような非常に単純な小さなプログラムの実行可能ファイルは、異なるフレーバーで実行されますか？または、再コンパイルする必要がありますか？

このような場合、マシンのアーキテクチャは重要ですか？

int main()
{
  return (99);
}

場合によります。IA-32（Intel 32ビット）用にコンパイルされたものは、Intel上のLinuxが32ビットアプリケーション（適切なソフトウェアがインストールされている）との後方互換性を保持するため、amd64で実行できます。ここにあなたのだcode（2002年頃、gccのバージョン2.96）のRedHat 7.3 32ビットシステム上でコンパイルして、バイナリにコピーし、（2017年頃）CentOSに7.4 64ビットシステム上で実行するには：

-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（本質的にRedHat Enterprise Linux 7.4）は同じ「ディストリビューション」ファミリーにとどまっているため、2002年からのランダムな「ゼロからのLinux」インストールから2018年に他のランダムなLinuxディストリビューションに移行するよりも移植性が高い可能性が高い。

amd64用にコンパイルされたものは、Linuxの32ビットのみのリリースでは実行されません（古いハードウェアは新しいハードウェアを認識しません）。これは、ライブラリやシステムコールでさえも後方への移植性がないため、古代の古いもので実行することを目的とした現代のシステムでコンパイルされた新しいソフトウェアにも当てはまります。そのため、コンパイルトリックや古いコンパイラーの入手などが必要になる場合があります古いシステムでコンパイルします。（これは古代の古いものの仮想マシンを保持する正当な理由です。）

アーキテクチャは重要です。amd64（またはIA-32）はARMまたはMIPSとは大きく異なるため、これらの1つのバイナリが別のバイナリで実行されることはありません。アセンブリレベルではmainIA-32上のコードのセクションは、経由してコンパイルgcc -S code.cします

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

これはamd64システムで処理できます（Linuxシステムでは、OpenBSDはamd64とは対照的に32ビットのバイナリをサポートしません。古いアーキテクチャとの後方互換性により、攻撃者はCVE-2014-8866や友人などにゆらぎを与えます）。一方、ビッグエンディアンMIPSシステムでは、 main代わりに次のようにコンパイルされます。

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

Intelプロセッサは何をすべきか分からないでしょうし、MIPSのIntelアセンブリも同様です。

QEMUまたは他のエミュレータを使用して外部コードを実行することもできます（おそらく非常にゆっくり）。

しかしながら！あなたのコードは非常にシンプルなコードなので、他のものよりも移植性の問題が少ないでしょう。プログラムは通常、時間とともに変化するライブラリ（glibc、opensslなど）を使用します。それらの場合、さまざまなライブラリの古いバージョンをインストールする必要がある場合もあります（たとえば、RedHatは通常、そのようなパッケージ名のどこかに「互換」を置きます）

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

または、おそらくglibcを使用する古い方法のABIの変更（アプリケーションバイナリインターフェイス）、またはC ++ 11または他のC ++リリースによる最近の変更について心配するかもしれません。ライブラリの問題を回避するために、静的（ディスク上のバイナリサイズを大幅に増やす）をコンパイルすることもできますが、古いバイナリがこれを実行したかどうかは、古いLinuxディストリビューションがほとんどすべてを動的にコンパイルしていたかどうか（RedHat：yes）によって異なります。一方、patchelf動的な（ELFですが、おそらくa.outフォーマットされていない）バイナリを再コンパイルして、他のライブラリを使用することができます。

しかしながら！プログラムを実行できることと、実際にそれを使用して何か有用なことを行うことは別のことです。古い32ビットIntelバイナリは、恐ろしくてバックポートされていないセキュリティ問題があるOpenSSLのバージョンに依存している場合、またはプログラムが最新のWebサーバーとまったく交渉できない可能性があります（最新のサーバーが古いプロトコルと古いプログラムの暗号を拒否する）、またはSSHプロトコルバージョン1がサポートされなくなる、または...

要するに、同じ（または互換性のある）アーキテクチャを使用して、あるホストから別のホストにコンパイル済みのバイナリを使用する場合、別のディストリビューションに使用するのはまったく問題ありません。ただし、コードの複雑さが増すと、インストールされていないライブラリにリンクされる可能性が高くなります。別の場所にインストール。または異なるバージョンでインストールされた場合、増加します。（Debianから派生した）Ubuntu Linuxホストでlddコンパイルすると、次の依存関係を報告するコードを例にとりgcc -o exit-test exit-test.cます。

$ 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)

明らかに、このバイナリは、たとえばMac（./exit-test: cannot execute binary file: Exec format error）にキックすると実行されません。RHELボックスに移動してみましょう：

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

まあ。これはなぜでしょうか？

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

このユースケースでも、共有ライブラリが見つからないため、フォークリフトは失敗しました。

ただし、でコンパイルするとgcc -static exit-test-static exit-test.c、ライブラリなしでシステムに移植できます。もちろん、ディスク容量を犠牲にして：

$ 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

別の実行可能な解決策は、新しいホストに必要なライブラリをインストールすることです。

U＆Lユニバースの多くのものと同様に、これは多くのスキンを持つ猫です。そのうちの2つは上記で概説しています。

優れた@thrigおよび@DopeGhotiの回答に加えて、UnixまたはLinuxを含むUnixライクなOSは、従来より常にバイナリよりもソースコードの移植性を重視して設計および調整されていました。

何もハードウェアを有する特定のか、あなたの例のように、単純な源であるならば、あなたはかなりの間からは全く何の問題もなく、それを移動させることができる任意のソースコードなどのLinuxまたはアーキテクチャのバージョンを限り、先のサーバはCの開発パッケージがインストールされているとして、必要なライブラリ、およびインストールされている対応する開発ライブラリ。

遠い古いバージョンのLinuxからより高度なコード、または異なるカーネルバージョンのカーネルモジュールのようなより特定のプログラムを移植する場合、非推奨のライブラリ/ API / ABIを考慮してソースコードを調整および変更する必要があります。

することで、デフォルト、あなたはほぼ確実に外部ライブラリの問題に実行されます。他の回答のいくつかは、これらの問題についてより詳細に説明しているので、私は彼らの仕事を複製しません。

ただし、Linuxシステム間で移植できるように、多くのプログラムをコンパイルすることはできます。キーは、Linux Standard Baseと呼ばれるツールキットです。LSBポータブルアプリケーションのちょうどこれらのタイプを作成するために設計されています。LSB v5.0用にアプリケーションをコンパイルすると、LSB v5.0を実装する（同じアーキテクチャの）他のLinux環境で実行されます。いくつかのLinuxディストリビューションはLSBに準拠しており、他のディストリビューションにはインストール可能なパッケージとしてLSBツールキット/ライブラリが含まれています。LSBツール（のlsbccラッパーなどgcc）を使用してアプリケーションを構築し、LSBバージョンのライブラリにリンクすると、移植可能なアプリケーションが作成されます。

多分。

それを壊す傾向があるものは含まれます。

1. 異なるアーキテクチャ。明らかに、まったく異なるアーキテクチャは機能しません（binfmt_miscを使用したユーザーモードqemuのようなものがない限り、それはほとんど通常の構成ではありません）。x86バイナリはamd64で動作しますが、必要な32ビットライブラリが利用可能な場合のみです。
2. ライブラリバージョン。soversionが間違っていると、ライブラリがまったく見つかりません。soversionは同じですが、実行中のライブラリよりも新しいバージョンに対してバイナリがビルドされている場合、新しいシンボルまたは新しいバージョンのシンボルのためにロードに失敗する可能性があります。特に、glibcはシンボルバージョン管理のヘビーユーザーであるため、新しいglibcに対してビルドされたバイナリは、古いglibcで失敗する可能性が非常に高くなります。

急速に変化するライブラリの使用を避けた場合、アーキテクチャの変更を避け、ターゲットとする最も古いディストリビューションでビルドすると、多くのディストリビューションで1つのバイナリが動作する可能性が高くなります。

前述のいくつかのことに加えて、実行可能ファイル形式にいくつかの変更が加えられています。ほとんどの場合、LinuxはELFを使用しますが、古いバージョンではa.outまたはCOFFを使用しました。

ウィキホールの始まり：

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

古いバージョンに新しいフォーマットを実行させる方法があるかもしれませんが、私は個人的にそれを調べたことはありません。