web-dev-qa-db-ja.com

LinuxでIntel C / C ++コンパイラを使用して、Windowsでリンクするオブジェクトファイルを作成することはできますか？

なぜ？

ソースに応じて、Intelコンパイラーは、x86アーキテクチャーの実行可能ファイル（5〜100％の実行時間の改善）で最も高速な実行ファイルを生成する可能性があります。

インテルはLinux向けのコンパイラーを非商用ライセンスの下で無料で提供しています（ページのどこかで無料で読んだと思います： インテル-非商用ソフトウェア開発 ）。学生向けの無料の非商用ライセンスもありますが、3つの主要なオペレーティングシステムすべてにツールが提供されていますが、このライセンスは適用されません（評判の制限によりリンクが削除されました）。

目標

I (as a non-student) would like to be able to use the Intel compilers for possible execution speed improvements under the non-commercial license to compile object files that can be linked to create executables and dynamic link libraries for Windows (and possibly OS X)

詳細：

this ドキュメントから私が推測したのは、インテルのコンパイラーがプラットフォームの主要なコンパイラーと互換性のあるオブジェクトファイルを作成することです。

サブ質問：

  1. WindowsおよびLinux（現在のバージョン）でのgcc、g ++、cl、mingw32、icc、icpc、およびiclのオブジェクトファイル形式は何ですか？
  2. mingw32クロスコンパイラーツールチェーンの一部を使用して目標を達成できますか？
  3. 生成されたオブジェクトファイルのメタデータが主な問題だと思いますか？

広告2：
mingw32-objcopyは、LinuxのIntelコンパイラ出力（おそらくELF）をMicrosoft互換のCOFFに変換できるようです（再配置可能なオブジェクトファイルを除く）。これが実際に機能することを誰かが確認できますか？

c++open-sourceccompilercross-platform
12
Hugo

クロスコンパイラを使用して、LinuxビルドマシンでWindows実行可能ファイルを作成することができます。しかし、Intelはそのようなクロスコンパイラを提供していません。

サブ質問に答えるには：

WindowsおよびLinux（現在のバージョン）でのgcc、g ++、cl、mingw32、icc、icpc、およびiclのオブジェクトファイル形式は何ですか？

オブジェクトファイルの形式は、オペレーティングシステム（または、それを構築するために使用されるコンパイラ）によって効果的に決定されます。これは、Windowsの場合は Portable Executable（PE） 形式で、Linuxの場合は [〜＃〜] elf [〜＃〜] 形式です。

Mingw32クロスコンパイラツールチェーンの一部を使用して目標を達成できますか？

いいえ。関連する部分はコードジェネレーターです。これは、適切なオブジェクト形式を生成する役割と、生成されたコードに速度Edgeを提供するIntelコンパイラー上の部分の両方です。

生成されたオブジェクトファイルのメタデータが主な問題だと思いますか？

いいえ。これは1つの問題ですが、それ以上の問題があります。さらに根本的な問題は、パラメータがカーネルや標準ライブラリに渡される方法に潜在的な違いがあることです。 IIRC、これらの規則はWindowsとLinuxで異なります。

1
Bart van Ingen Schenau

答えはほぼ間違いなくイエスです。 Linuxボックスで（ mingw32 を介して）Windowsバイナリをクロスコンパイルすることは、gccを使用して簡単に実行できることを知っています-当然、Linuxでプログラムを実行することはできません（Wineで動作しない場合）。しかし、私はこの方法でWindowsバイナリを取得するいくつかのプログラムを知っています。

ただし、インテルコンパイラーにこれを行うオプションがあるかどうかはわかりません。

Windowsのオブジェクト形式は [〜＃〜] pe [〜＃〜] ですが、Linuxの場合は [〜＃〜] elf [〜＃〜] です。

0
gbjbaanb

私は次の答えを提案します：

多分（yesに寄りかかる）がaであるがコンテキストに関して

説明：「寄りかかる」部分について：これを試すのは時間の無駄ではないようですが、（「置く」部分）を考慮に入れる この答え インテルのみのツールチェーンと比較した実行時間の改善。関連する部分は、コンパイラーへのリンカーとランタイムのフィードバックです（プログラム全体の最適化、プロファイルに基づく最適化、リンク時のコード生成）。

追加の詳細：
MinGW FAQ によると、ライブラリとDLLの使用に問題がある可能性があります：
"dllはさまざまなWindowsコンパイラ間でかなり移植可能であると想定されていますが、ライブラリファイル（.libまたは.a）を介してdllにアクセスすることはできません。ライブラリファイル形式は特定のコンパイラに固有であり、コンパイラがサポートを提供しない限り、異なるコンパイラ。」

答えを完成させるには：
サブ質問1：

WindowsおよびLinux（現在のバージョン）でのgcc、g ++、cl、mingw32、icc、icpc、およびiclのオブジェクトファイル形式は何ですか？

Windows上のコンパイラのデフォルトのオブジェクトファイル形式は [〜＃〜] coff [〜＃〜] （おそらく [〜＃〜] pe [〜＃〜] ですバリアント）。 Linux上のコンパイラのデフォルトのオブジェクトファイル形式は [〜＃〜] elf [〜＃〜] です。

サブ質問2：

Mingw32クロスコンパイラツールチェーンの一部を使用して目標を達成できますか？

可能性が高い（リンク部分の場合）が、実行時間はそれほど改善されない可能性が高い.

サブ質問3：

生成されたオブジェクトファイルのメタデータが主な問題だと思いますか？

リンクについて：はい。

0
Hugo

Microsoftのカスタム呼び出し規約を使用するCコードが（直接）何にもリンクしない場合、MinGWのobjcopyを使用する可能性があります。アセンブルされたオブジェクトファイルを変換するために使用しましたが、呼び出し規約について心配する必要はありませんでした。

私はあなたがこれをやろうとしている時間を費やすだけで、GCCやclangにあなたが望んでいることを正確に行わせます。そのような高速化が本当に重要な場合は、LinuxバイナリをIntelコンパイラでコンパイルし、コードの高速化を行っていることを正確に調べます。他のすべてが失敗した場合は、アセンブリにパッチを適用できます。

0
Ericson2314