Linux では、クロスコンパイルとは、あるプラットフォーム上で別のプラットフォーム上で実行可能コードを生成することを指します。つまり、ソース コードをコンパイルするプラットフォームと、ソース コードのコンパイルされたプログラムを実行するプラットフォームは 2 つの異なるプラットフォームです。 。クロスコンパイルを使用する理由: 1. ターゲット システムにはネイティブにコンパイルする機能がない; 2. ソース コードをコンパイルできるプラットフォームはターゲット プラットフォームとは異なります。
#このチュートリアルの動作環境: linux5.9.8 システム、Dell G3 コンピューター。
クロスコンパイル
いわゆる「クロスコンパイル (Cross_Compile)」とは、ソース コードをコンパイルするためのプラットフォームを指します。ソース コードがコンパイルされた後のプログラムの実行 プラットフォームは 2 つの異なるプラットフォームです。たとえば、Intel x86 アーキテクチャ/Linux (Ubuntu) プラットフォームでは、クロスコンパイル ツール チェーンを使用して生成された実行可能ファイルは、ARM アーキテクチャ/Linux で実行されます。
簡単に言えば、あるプラットフォーム上で別のプラットフォーム上で実行可能コードを生成することです。同じアーキテクチャで異なるオペレーティング システムを実行でき、同様に、同じオペレーティング システムを異なるアーキテクチャでも実行できます。
クロスコンパイルは比較的複雑であり、次の問題を考慮する必要があります:
CPU アーキテクチャ: ARM、x86、MIPS、など;
エンディアン: ビッグエンディアンとリトルエンディアン;
浮動小数点数のサポート;
アプリケーション バイナリ インターフェイス (ABI);
クロスコンパイルを使用する理由主な理由は 2 つあります。
クロスコンパイルのターゲット システムには通常、メモリが少なく、表示装置が貧弱であるかまったくなく、ローカルでコンパイルする機能がありません。 ;
ソース コードをコンパイルできるプラットフォームの CPU アーキテクチャまたはオペレーティング システムがターゲット プラットフォームと異なります;
クロスコンパイルツールチェーンはクロスコンパイルに必要であり、組み込み開発者にとって不可欠なツールであり、習得しなければならないスキルです。
クロスコンパイルはなぜ難しいのでしょうか?
移植可能なネイティブ コンパイルは困難です。
ほとんどのプログラムは x86 ハードウェアで開発され、ネイティブにコンパイルされます。クロスコンパイルでは、プログラム自体の問題とビルド システムの問題の 2 種類の問題が発生する可能性があります。
最初のカテゴリの問題は、ネイティブ ビルドやクロス ビルドを含む、x86 以外のすべてのターゲットに影響します。ほとんどのプログラムは、実行されているマシンのタイプを推測します。これは、関連するプラットフォームと一致する必要があり、そうでない場合、プログラムは実行されません。一般的な前提条件は次のとおりです。
ワード サイズ - ポインタを int にコピーすると、64 ビット プラットフォームではデータが失われる可能性があります。sizeof(long) の代わりに 4 を乗じて malloc サイズを決定するのは適切ではありません。整数オーバーフローは、「if (x y
エンディアンネス - システムが異なれば、バイナリ データは内部的に異なる方法で保存され、ディスクまたはネットワークから int または float データを読み取るには変換が必要になる場合があります。
アライメント - 一部のプラットフォーム (arm など) は、4 バイトの偶数倍のアドレスからの整数の読み取りまたは書き込みのみが可能です。そうでない場合は、セグメンテーション違反が発生します。整列されたデータと整列されていないデータの処理は遅くなり、通常はコンパイラーが構造体整列変数を埋めます。構造をディスクまたはネットワーク上に送信できるデータのブロックとして扱うには、一貫した表現を保証するために追加の作業が必要です。
デフォルトの署名 - 「char」データ型は、デフォルトで署名付きまたは署名なしですが、プラットフォームごとに (コンパイラごとに) 異なり、いくつかの非常に驚くべきバグにつながります。簡単な回避策は、デフォルトを既知の値に強制する「-funsigned-char」などのコンパイラ パラメータを提供することです。
NOMMU - ターゲット プラットフォームにメモリ管理ユニットがない場合は、いくつかの点を変更する必要があります。 fork() ではなく vfork() が必要です。特定のタイプの mmap() のみが機能します (共有または読み取り専用ですが、コピーオンライトは機能しません)。スタックは動的に増加しません。
ほとんどのパッケージは、ネイティブにコンパイルされたときに移植可能であることを目指しており、適切な開発メーリング リストに提出された上記の問題 (NOMMU の問題を除く) のいずれかを修正するパッチを少なくとも受け入れます。
続いてクロスコンパイル。
ネイティブ コンパイルの問題に加えて、クロスコンパイルには独自の問題があります。
構成問題 - 通常、エンディアンネスやページ サイズなどをテストする別の構成ステップ (標準の configure/make/make install の「./configure」部分) を持つパッケージは、ネイティブにコンパイルすると移植可能です。クロスコンパイル時、これらの値はホスト システムとターゲット システムで異なり、ホスト システムでテストを実行すると不正確な結果が得られます。ターゲットにソフトウェア パッケージがない場合、またはバージョンに互換性がない場合、構成はホストにソフトウェア パッケージのサポートがあるかどうかを検出します。
HOSTCC と TARGETCC - ビルド プロセスでは、テスト用に上記で構成したホスト システム上で実行するコンパイル、またはコードを生成するプログラム (.h ファイルを作成する C プログラムなど) が必要です。 #メインビルド中に含まれます)。ホスト コンパイラをターゲット コンパイラに置き換えると、ビルド プロセス中にランタイム ライブラリが破壊されます。このようなライブラリはホストおよびターゲット コンパイラにアクセスする必要があり、それを使用するタイミングを指定する必要があります。
ツールチェーンの漏洩 - 不適切に構成されたクロスコンパイル ツールチェーンにより、ホスト システムの内容の一部がコンパイルされたプログラムに漏洩し、多くの場合、検出は簡単ですが、診断と診断が困難な障害が発生します。正しい。 。ツールチェーンは、リンク時に間違ったヘッダー ファイルを #include したり、間違ったライブラリ パスを検索したりする可能性があります。共有ライブラリは他の共有ライブラリに依存していることが多く、予期しないリンク時の参照がホスト システムに侵入する可能性があります。
ライブラリ - 動的にリンクされたプログラムは、コンパイル時に適切な共有ライブラリにアクセスする必要があります。ターゲット システムの共有ライブラリは、プログラムがリンクできるようにクロスコンパイル ツール チェーンに追加する必要があります。
テスト - ネイティブ ビルドでは、開発システムは便利なテスト環境を提供します。クロスコンパイル時に、「hello world」ビルドが成功したことを確認するには、(少なくとも) ブートローダー、カーネル、ルート ファイルシステム、および共有ライブラリの構成が必要になる場合があります。
Linux ビデオ チュートリアル 」
以上がLinuxクロスコンパイルとは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。