x86 で実行される C コードや ARM CPU で実行される C コードなど、CPU アーキテクチャに依存するソフトウェアを作成する場合。一般に、このコードをコンパイルするには 2 つの方法があります。ARM CPU arch にクロスコンパイルする (x86 システムで開発している場合など) か、コードをネイティブ arch cpu システムにコピーして単純にコンパイルします。
ネイティブ アプローチとクロスコンパイル アプローチに利点があるかどうか疑問に思っています。Fedora ARM チームが、低速/低電力の ARM デバイスのビルド サーバー クラスターを使用して、Fedora ARM スピンを「単純に」コンパイルしていることに気付きました...確かに、Red Hat が支援するプロジェクトは、x86 cpu を実行するいくつかの強力なビルド サーバーにアクセスできます。 2 分の 1 の時間で仕事を終わらせることができる... では、なぜ彼らが選択したのでしょうか? ソフトウェアをクロスコンパイルすることで、何か不足していますか?
主な利点は、./configureネイティブで実行する場合、すべてのスクリプトを微調整する必要がないことです。シャドウrootfsを使用している場合でも、CPU タイプなどを検出するための構成が実行されていますuname。たとえば、この質問を参照してください。および他のツールはクロスビルドpkgconfigを容易にしようとしますが、パッケージは通常、最初にx86で正しくネイティブ ビルドされ、次にARMでネイティブ ビルドされる可能性があります。各パッケージには個別の微調整が必要な場合があるため、クロスビルドは苦痛になる可能性があります。
最後に、Joachimに従ってプロファイル ガイド付き最適化を実行し、テスト スイートを実行している場合、クロス ビルド環境でこれを行うことはほとんど不可能です。
ARMでのコンパイル速度は、人間のパッケージ ビルダー、読み取りconfigure、編集configure、構成の再実行、コンパイル、リンクのサイクルよりも大幅に高速です。
これは、継続的インテグレーション戦略にも適しています。さまざまなパッケージ、特にライブラリをすばやくビルド/デプロイ/テストできます。ライブラリのテストには、何百もの依存パッケージが含まれる場合があります。通常、 Arm Linux ディストリビューションは、少なくとも再テストが必要な数百の依存パッケージを含む可能性のあるベース ライブラリをアップグレードしてパッチを適用するときに、変更のプロトタイプを作成する必要があります。コンピューターによって実行される低速のサイクルは、手動の人間の介入が続く高速のコンパイルよりも常に優れています。
いいえ、技術的には、.c -> .o -> a.out (または何でも) のコンテキスト内でクロスコンパイルすることによって、何も見逃していません。クロス コンパイラは、ネイティブ コンパイラと同じバイナリを提供します (バージョンなどに関係なく)。
ネイティブにビルドすることの「利点」は、コンパイル後のテストと複雑なシステムの管理から得られます。
1) コンパイル後に単体テストをすばやく実行できれば、バグや問題にすばやく対処できます。サイクルはおそらくクロスコンパイル サイクルよりも短くなります。
2) サードパーティのライブラリを使用するターゲット ソフトウェアをコンパイルしている場合、それらをビルドしてデプロイし、それらを使用してターゲットをビルドする方が、ネイティブ プラットフォームの方がおそらく簡単です。それらのクロスコンパイル ビルドに対処したくありません。なぜなら、それらの半分には、クロス コンパイルを面倒にする狂った猿によって書かれたビルド プロセスがあるからです。
通常、ほとんどの場合、ベース ビルドに到達し、残りをネイティブにコンパイルしようとします。クロス コンパイラが非常に高速で、残りの作業 (単体テストや依存関係の管理など) を簡単にするために必要なセットアップを行うだけの価値がある時間を節約できるようなセットアップをしている場合を除きます。
少なくともそれは私の考えです
ネイティブ コンパイルの唯一の利点は、プログラムが既に存在するため、ターゲット プラットフォームにプログラムを転送する必要がないことです。
ただし、ほとんどのターゲット プラットフォームが最新の x86 PC に比べて大幅に能力不足であることを考えると、それほど大きな利点ではありません。大量のメモリ、より高速な CPU、特にはるかに高速なディスクにより、PC でのコンパイル時間が何倍も速くなります。そのため、ネイティブ ビルディングの利点はもはや実際には利点ではありません。
コンパイラに大きく依存します。ツールチェーンは、ネイティブとクロス コンパイルの違いをどのように処理しますか。ツールチェーンがクロスコンパイラとしてビルドされていると常に考えているだけの場合ですが、それをビルドする1つの方法は、手動で行うのではなく、configureスクリプトにホストを自動検出させることです（プレフィックスを自動設定するなど） )?
Dont assume that just because it is built to be a native compiler it is really native. There are many instances where distros dumb down their native compiler (and kernel and other binaries) so that that distro runs on a wider range of systems. On an ARMv6 system you might be running a compiler that defaults to ARMv4 for example.
That begs a similar question to your own, if I build the toolchain with one default architecture then specify another is that different that building the toolchain for the target architecture?
Ideally you would hope that a mostly debugged compiler/toolchain would give you the same results whether you were native or cross compiled and independent of the default architecture. Now I have seen on an older llvm that the llvm-gcc when run on a 64 bit host, cross compiling to arm would build all ints as 64 bit adding a lot to the code, same compiler version, same source code on a 32 bit host would give different results (32 bit ints). Basically the -m32 switch did not work for llvm-gcc (at the time), I dont know if that is still the case as I switched to clang when doing llvm work and never looked back at llvm-gcc...llvm/clang for example is mostly a cross compiler all the time, the linker is the only thing that appears to be host specific, you can take an off the shelf llvm and compile for any of the targets on any host system (provided your build didnt disable any of the supported targets of course).