8

あるディストリビューションでGCC4.7.xでコンパイルされたC++バイナリが別のディストリビューションで直接使用されている場合に影響を与える、ディストリビューション間の特異性やバリエーションはありますか？理想的な状況は2番目のディストリビューションでソースからコンパイルすることであることを理解していますが、新しいGCCバージョンとプログラムソースコードを実稼働マシンでコンパイルすることについて心配する必要はありません。私は比較的経験の浅いLinuxユーザーであり（したがって質問です！）、コマンドラインコンパイルではなくIDEを好みます。実際に本番マシンにアクセスするために使用できるのはsshだけです。

コード自体は興味深いものではありませんが、ブロッキングソケットなどのミルOS機能の実行を利用しています。

アドバイスをいただければ幸いです。

4

4 に答える 4

5

バイナリがまったく同じOS（バージョンを含む）とまったく同じハードウェアで構築されていない限り、保証はありません。

実際には：

  1. ハードウェアが同じチップファミリである場合は、機能するはずです。

    • これは、ほとんどの人がハードウェア固有の最適化をオンにしないためです（ただし、オンにすることはできます）。
    • チップセット間でバイナリを移動することはほとんど機能しません
    • ハードウェアファミリの古いメンバーから新しいメンバーへのバイナリの移動は機能する可能性があります
    • ハードウェアファミリの新しいメンバーから古いメンバーにバイナリを移動する可能性は低くなります（ただし、最適化とコンパイラの設定に依存します（64ビットアーキテクチャから32ビットアーキテクチャへの移動は機能しない可能性があります）。

  2. OSのメジャー番号が同じであれば、（おそらく）機能するはずです。

    • バイナリが機能するOSのバージョンは、バイナリのビルドに使用されたコンパイラのバージョンとホストOSによって異なります。
    • コンパイラーが生成するABIに変更がある場合、すべての賭けは無効になります。ただし、通常、コンパイラによって生成されるABIの変更は大きな問題になるため、OSロードマップの主要なポイントでのみ発生します（小さな増分では発生しません）。

  3. 私のアドバイスは情報源から構築されています。

    • 特に外に出て開発環境を更新しないでください（ディストリビューションに付属しているものを使用してください（デフォルトの更新を行う場合、下位互換性が損なわれることはありません））。
    • ファイルを読むだけで簡単に作成できREADMEます。ただし、通常は2つのコマンド./configureとを実行する必要がありますmake。特別なことをしたくない場合は、通常、他に何もする必要はありません。
于 2012-10-19T15:35:12.053 に答える
3

G ++はかなり長い間安定したABIを持っていたので、それが問題を引き起こすことはないはずです。問題を引き起こす可能性が高いのは、動的にリンクされたライブラリを使用することです。プログラムを実行するシステムには、実行可能ファイルがコンパイルされた共有ライブラリの互換性のあるバージョンが必要です。静的リンクのみを使用する場合は、問題はありません。オプションを使用して、静的リンクをオンにでき-staticます。

于 2012-10-19T15:29:57.730 に答える
3

静的リンケージでは、次の2つの条件を満たす必要があります。

1）ターゲットシステムとビルドシステムは同じアーキテクチャである必要があります（例外：多くの64ビットホストで32ビットバイナリを実行できます）

2）ターゲットシステムの（g）libcパッケージは、ビルドシステムよりも古いバージョンであってはなりません（バージョンのわずかな違いで解決できる場合があります）

動的リンケージではさらに複雑になります。

于 2012-10-19T15:31:47.637 に答える
0

一般に、新しいディストリビューションで構築されたバイナリは古いバージョンでは機能しませんが、古いディストリビューションで構築されたバイナリは新しいディストリビューションで機能します。今のところ、RedHat EL4でバイナリをビルドすると、サポートされているほとんどのディストリビューションで動作します（欠落している場合はlibstdc ++をコピーする必要があるかもしれません）

于 2012-10-19T15:27:00.057 に答える