コンパイラは通常、インストールされているプラ​​ットフォームの実行可能ファイルのみを生成するのはなぜですか？

私はC ++開発者であり、クロスプラットフォーム開発をよりよく理解するために、コンパイラーの実装の詳細と、コンパイラーがOS固有のバイナリーを正確に作成する方法をよりよく理解しようとしています。私の調査の最中に、少なくともしばらくの間、特定のプラットフォーム用にダウンロードしたほとんどのコンパイラーは、そのプラットフォーム用のバイナリーのみをコンパイルすることに気付きました。したがって、Windows用のコンパイラexeが付属しているIDEをダウンロードした場合、そのコンパイラはx86-x64 Windowsアプリケーション用のプログラムのみをコンパイルでき、LinuxまたはMacアプリケーションはコンパイルできません。

現在、プラットフォームごとに異なるバイナリ形式が必要であることを理解していますが、WindowsのビジュアルC ++コンパイラーがLinuxバイナリ実行可能ファイルを生成するのが難しいのはなぜですか？実行中のCPUのアセンブリ命令とOS固有のライブラリがある限り、任意のマシンの任意のプラットフォーム用の実行可能ファイルをコンパイルできませんか？

WindowsのビジュアルC ++コンパイラーがLinuxバイナリ実行可能ファイルを生成するのが難しいのはなぜですか

Microsoft側でそれを実行したくないという以外は、まったく何もありません。障害は技術的なものではありません。

開発ツールチェーンは、入力を受け取り、出力を生成する単なるプログラムです。Visual C ++はx86アセンブリを生成し、アセンブラを使用してそれをCOFFオブジェクトファイルに変換します。Microsoftが代わりにELFを生成するようにしたい場合、それは単なるコードです。アセンブリが入ってきて、ELFが出ます。オブジェクトファイルやライブラリに魔法はありません。それらは、よく理解された形式の単なるデータの塊です。

石器時代にさかのぼると、クロスコンパイルははるかに困難でした。それは、たいていの場合、ターゲットプラットフォームのツールチェーンを、それが実行されるプラットフォームのアセンブリで作成していたためです。つまり、VAX、M68K、Alphaアーキテクチャが世界中にあったとしても、クロスコンパイラの完全なスイートでは、それらのほとんどをゼロから作成する必要がありました。（VAX-to-VAX、VAX-to-M68K、VAX-to-Alpha、M68K-to-VAX、M68K-to-M68Kなど）VAXコンパイラーの一部は再利用でき、各ターゲットのコードジェネレーター（VAX、M68K、Alphaなど、VAX用に作成されたもの）に接続されています。

この問題は、Cなどの特定のプロセッサに関連付けられていない言語でコンパイラを作成し始めたときに解消されました。そのルートに進むと、Cでツールチェーン全体を1回記述し、ローカルプラットフォーム向けに作成したそれをビルドするCコンパイラ。（ローカルプラットフォームのコンパイラーでブートストラップされた後、コンパイラーを使用して再コンパイルすることがよくありますが、これは別の議論です。）クロスコンパイラーの構築は、ネイティブコンパイラーの構築と本質的に同じ努力になったということです。ローカルプラットフォーム。唯一の重要な違いは、ビルドプロセスのどこかで、ローカルプラットフォーム用のコードジェネレーターではなく、ターゲットプラットフォーム用のコードジェネレーターでコンパイルするように指示したことです。

コンパイラーのアーキテクチャーが進化するにつれて、すべてのコードジェネレーターを製品に含めてビルドし、実行時に使用するコードジェネレーターを選択するのが便利になりました。Clang / LLVMがこれを行います。他にもあると思います。

機能するツールチェーン（コンパイラー、アセンブラー、リンカー）を取得すると、ライブラリーはソースからビルドされ、最終的には他のプラットフォーム用の実行可能ファイルを作成するために必要なすべてのものが揃います。

はい、ターゲットプラットフォームに関するすべての情報を入手している場合は、実際に実行しているプラ​​ットフォームは問題ではありません。

発生する傾向のある2つの問題があります。

1. あまり一般的でないシナリオであるため、人々はそれに焦点を合わせません。多くの場合、クロスコンパイルするのはコンパイラだけなので、クロスコンパイルを停止できます。焦点を絞らないとサポートが悪化します。
2. 重要なプログラムには、単なるコード以上のものが必要です。ライブラリのインクルード/リンケージの処理は、実行しているプラ​​ットフォーム用のライブラリがある場合は少し簡単になります。それらは、よく知られている場所に、よく知られているエンコーディングで配置されます。

もちろん、それらを克服することはできません。ほとんどの場合、それが実行されるプラットフォームをターゲットとするコンパイラーを入手します。

私はあなたの前提に同意しません。何百万ものAndroidおよびiOS開発者がいます。そして、それらはすべて WindowsまたはMacで実行されるコンパイラーを使用して、まったく異なるコンピューター用のコードを生成します。

市場での需要がない場合は、クロスコンパイラを入手できません。たとえば、Linuxデスクトップ用のコードを開発している人は、ほとんどの場合Linuxデスクトップが利用可能であり、Linuxベースのコンパイラを使用します。アプリケーションをネットワーク経由で転送せずにコンパイルされたマシンで直接実行できる場合は、はるかに速く、はるかに簡単で高速です。同じマシンでデバッガーを実行する場合など。

では、コンパイラがLinux用にもビルドされるとしたら、Microsoftはどれだけ多くのお金を稼ぐでしょうか？約$ 0。Windows用のソフトウェアはどれくらい作成されますか？無し。どのくらいのLinuxソフトウェアが作成されますか？わかりませんが、Microsoftが気にすることではありません。費用はいくらですか？かなりかなり。コンパイラーにはバグがない必要があります。テストする必要があります。

別の問題：Windowsでコンパイラーを作成する場合、Windowsソフトウェアの作成方法を知っている人が必要です。Linux用のコンパイラーを作成する場合、Linuxソフトウェアの作成方法を知っている人が必要です。Windowsで実行するLinux用のコンパイラを作成する場合、突然、WindowsとLinuxの両方を知っている、よりまれな開発者のパンが必要になります。