5

最初のメモ: AIX は最初のコンテキストであるため、質問は AIX に言及していますが、質問は実際にはプラットフォームに関係なく gcc 自体に関係しています。

AIX は下位バイナリ互換であると想定されています。AIX 5.1 でコンパイルされた C プログラムは、5.2、5.3、6.1、および 7.1 でそのまま実行されます。

私の理解では、gcc は特定のシステム (クロスコンパイルの場合は現在のシステムか別のシステムか) をターゲットにするようにビルドする必要があります。そのため、AIX 6.1 上に構築された gcc は AIX 6.1 をターゲットとし、バイナリ互換性のおかげで 6.1 と 7.1 の両方で使用可能なバイナリを生成します。

ただし、AIX 6.1 上にビルドされた gcc 自体は 6.1 プログラムなので、7.1 上でそのまま実行する必要があります。もちろん、7.1 でプログラムをコンパイルすると、このプログラムはリンクされたり、7.1 に固有のヘッダーを使用したりする可能性があるため、7.1 を必要とするバイナリが生成されます。私が理解している限りでは、AIX 6.1 でビルドされた gcc を 7.1 マシンで実行でき、リンクの副作用として 7.1 が必要になるものの、最適ではないものの完全に有効なバイナリを生成できるはずです。

これは、きらめく空で踊る虹やユニコーンのように見えます. 何か怪しい匂いがしますが、gcc 内部の知識がありません。大群衆よ、私を啓発してください。

tl;dr : OS/プラットフォームのバージョン N を対象として構築された gcc は、バージョン N+1 で実行されるバイナリを生成するプラットフォーム バイナリ互換性により、バージョン N+1 で実行および使用できますか? そうでない場合、それを防ぐメカニズムは何ですか？

4

1 に答える 1

2

ここに啓発があります：あなたの質問はあまりにも一般的です. それに答えるには、誰かが知識を持っている必要があります

  • 気になるオペレーティングシステム
  • 気になるOSのバージョン
  • 気になるgccのバージョン

次に、この 3 次元マトリックスでバイナリ互換性を調査します。

バイナリ互換性を妨げるメカニズムが多すぎて、OS とコンパイラ ベンダーがそれを破ろうとする創意工夫に直接関係しています。より一般的で文書化された方法の 1 つは、API 呼び出しの公式な非推奨、出荷された互換性ライブラリの削除、a.out から ELF への移行などのブリッジの焼却です。

于 2011-09-03T15:24:12.280 に答える