*nix実行可能ファイルの互換性

短い答え：いいえ。

通常のレベルの回答：ターゲットオペレーティングシステムでサポートされている場合はそうです。

答えが長いです...

最初に注目すべき点は、ベンダーごとに異なるチップセットを使用できることです。したがって、SolarisバイナリはSPARCチップ用にコンパイルできます。 Intel / AMDシステムでは機能しません。同様に、AIXもPowerPCにあります。 HP-UXはPA-RISCにあります。これらすべての問題を無視して、「Intel / AMD」スペースに集中します。

次の問題は、異なるオペレーティングシステムが異なるカーネルを公開する可能性があることです。システムコール。これは、アプリケーションによるカーネル呼び出しが期待どおりに機能しないことを意味します。これは明らかに問題です。ただし、ターゲットカーネル可能「ABI互換性層」を提供する機能、カーネル（FreeBSDカーネル仮定）はLinuxバイナリを実行しようとしていることを検出し、LinuxカーネルABIとデフォルトカーネルABIの間で変換できます。

これNext問題はライブラリの1つです。 Linuxバイナリは、ホスティングオペレーティングシステムにない可能性がある特定のバージョンのglibcをロードできると予想しています。これ可能この問題は、必要なライブラリをコピーすることで解決できます。繰り返しますが、オペレーティングシステムは、これらのライブラリを簡単にインストールできるようにパッケージを提供するなど、簡単に作成できます。

すべてのバイナリの後可能ランニング:-)

1990年代に、Linuxにはこれらの作業を可能にするiBCSモジュールがありました。たとえば、LinuxでSCO Unixプログラムを実行できます。概念証明として、私のコンピュータでSCO Unix Oracleを実行しました。効果はとても良いです！明らかにサプライヤーのサポートがないため、本番には適していません。 :-)

Linuxはこの分野で大きな足場を築くようになり、他のオペレーティングシステムでは、Linuxプログラムがそのオペレーティングシステムで実行できるように互換性層を追加しようとしています。

したがって、オペレーティングシステムがサポートしている場合そして正しくインストールして設定したら可能他のUnixでいくつかのプログラムを実行する能力。

いいえ、ほとんどの場合、実行可能ファイルは実行されません。同じカーネルの変更により、オペレーティングシステムのバージョンが変わりました。

以前に見た簡単な例は、dmesgOpenBSDのコマンドがすべてのカーネルメッセージ（ブート情報など）が行くシステムメッセージバッファを出力することです。最近カーネルを再コンパイルしましたが、突然次dmesgのように戻りました。

dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory

これは、userlandユーティリティが再コンパイルされず、実行可能ファイルがそのdmesg操作を実行できないという意味で「作業中」として認識されるためです（カーネルコードの変更による）。

したがって、dmesg以前のバージョンは最新のオペレーティングシステムで「動作」しません。

編集する(コメントのコメント、追加を含む)

カーネルのシステムコールをAPIと考えてください。 APIを変更できない場合、または以前のバージョンとの互換性を常に維持する必要がある場合は、どういう意味ですか？これは設計上の欠陥ではなく、ソフトウェアが動作する一般的な方法です。

あるAPIバージョン用にコンパイルされた実行コードがそのAPIの他のバージョンで動作することを期待することはできません。 API/カーネル開発者として、OSを追加して改善するよりも、以前のバージョンとの互換性を破ることに興味があります。

幸いなことに、UnixシステムのほとんどのソフトウェアはPOSIX規格に従って設計されています。源泉実行可能ファイルの内容はシステムタイプ間で転送でき、ほぼどこでもコンパイルして実行できます。 Unixプラットフォーム間のバイナリ互換性の問題は、次の場合にのみ問題になります。

• 非POSIX拡張が必要です。
• ソースコードはプライベートソースです。