web-dev-qa-db-ja.com

Visual StudioにネイティブAMD64ツールチェーンを使用させる方法

Visual Studio 2012で、デフォルトのx86_AMD64クロスコンパイラーではなく、ネイティブAMD64ツールチェーンを使用するにはどうすればよいですか？

プログラム全体の最適化とリンク時のコード生成を実行すると、リンカーがメモリ不足になる大きなライブラリを構築しています。

同じ質問をする2つの古い投稿（ here および here ）を見つけましたが、まだ回答はありません。 Microsoftは、ツールチェーン コマンドライン の指定方法に関するドキュメントを提供していますが、IDEでは提供していません。

c++visual-studiocompilation64-bit
32
Ky Waegel

Visual Studio 2012 IDEを起動する前に、環境変数 "_IsNativeEnvironment"を "true"に設定する必要があります。

set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln

Visual Studio 2013では、環境変数の名前が異なります。

set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln

IDEのバージョンがツールチェーンのバージョンと一致しない場合、この手法は機能しません。つまり、VS2013を使用する場合IDE VS2012コンパイラを実行すると、あなたは運が悪いですが、そのような組み合わせは珍しいです。

詳細については、次のリンクをご覧ください。

VS12とVS13の違い

VS13のプロジェクトにPreferredToolArchitectureを埋め込む方法

33
Denis Gurchenkov

Visual Studio 2013のプロジェクトごとに64ビットリンカーの使用を強制する別の方法があります。vcxprojファイルを編集し、<Import...Microsoft.Cpp.Defaults行の後に以下を挿入します。

  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
  <PropertyGroup>
    <PreferredToolArchitecture>x64</PreferredToolArchitecture>
  </PropertyGroup>
36
the_mandrill

目的が具体的にAMD64_x86ではなくnative環境を使用することである場合、プロジェクトファイルでUseNativeEnvironmentプロパティを設定できます。

<PropertyGroup>
  <UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>

（「Globals」PropertyGroupに正常に追加しました。）

/Bvコンパイラー・オプションを追加することにより、どのツールチェーンが使用されているかを確認できます。出力例を以下に示します。 toolchainディレクトリはbin\（この場合はAMD64_x86）の後に表示されることに注意してください。

2>ClCompile:
2>  Compiler Passes:
2>   C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\CL.exe:        Version 18.00.31101.0
2>   C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\c1.dll:        Version 18.00.31101.0
2>   C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\c1xx.dll:      Version 18.00.31101.0
2>   C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\c2.dll:        Version 18.00.31101.0
2>   C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\link.exe:      Version 12.00.31101.0
2>   C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64\mspdb120.dll:      Version 12.00.31101.0
2>   C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\1033\clui.dll: Version 18.00.31101.0
8
Ross Bencina

私はこれがかなり古い投稿であることを知っていますが、それでもVS 2017に関連しています。ここでも、「PreferredToolArchitecture」環境変数があり、IDE 。

ただし、プロジェクトベースごとにプロジェクトに簡単に統合できるため、使用するツールアーキテクチャを常に選択できます。多分これはいくつかのために役立ちます。これを行う：

  • プロパティマネージャーに移動し、新しいプロパティシートを作成します。 g。 「x64 Toolchain.props」という名前になっているので、それが何をするのかがわかります。別のプロパティシートを使用すると、シートをプロジェクトに含めるか含めないかで、ツールアーキテクチャを適切に切り替えることができます。
  • その新しいシートのプロパティを開き、「共通のプロパティ\ユーザーマクロ」に移動して、「マクロを追加」をクリックします。
  • ダイアログで、名前を「PreferredToolArchitecture」、値を「x64」に設定し、「このマクロをビルド環境の環境変数として設定する」チェックボックスをオンにします。
  • 必要に応じて、「共通のプロパティ\ C/C++ \コマンドライン」に移動し、「追加オプション」の下に「/ Bv」を追加します。これにより、パスとバージョン番号を含め、コンパイラーが使用するツールの出力が作成されます。目的のアーキテクチャーが実際に使用されているかどうかを確認するのに役立ちます。次のようにログ出力ウィンドウにエントリが配置されます：

    コンパイラパス：
    C：\ Program Files（x86）\ Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe：バージョン19.15.26730.0
    C：\ Program Files（x86）\ Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll：バージョン19.15.26730.0
    C：\ Program Files（x86）\ Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll：バージョン19.15.26730.0
    C：\ Program Files（x86）\ Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll：バージョン19.15.26730.0
    C：\ Program Files（x86）\ Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe：バージョン14.15.26730.0
    C：\ Program Files（x86）\ Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll：バージョン14.15.26730.0
    C：\ Program Files（x86）\ Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll：バージョン19.15.26730.0

  • ここで、x64ツールアーキテクチャでビルドする必要があるすべてのプロジェクトで、プロパティマネージャーのプロジェクトに新しいプロパティシートを含めます。そして、単にそれを含めてはならない人たちのために。それでおしまい。

HTH

編集：残念ながら、これは信頼できません！以下のコメントを参照してください。 MSがこの設定をいくつかのGUI要素に関連付け、一貫して機能させるようにしていただければ幸いです...

1
Don Pedro

XP 64 SP2でVisual Studio 2010を使用して同様の問題があります。VC++実行可能ディレクトリをAMD64 bin（ネイティブx64フォルダー）に検索パスの最初として設定した場合、 TRK0002エラーを受け取りました…無効なハンドル値。

しかし、Visual Studio 2010のコマンドプロンプトで_IsNativeEnvironment = trueを設定し、以前に投稿したようにコマンドラインからIDEを開始すると、エラーは発生しなくなります。どうやら、32ビットGUI IDE環境は64ビットプロセスから情報を受け取り、x86\cl.exeやx86_64\cl.exeなどの32ビットプロセスからの情報を期待しています。

IA64ビット実行可能ファイルをコンパイルするシナリオで、x86_ia64\cl.exeコンパイラを使用します。 32ビットクロスコンパイラーを使用していて、_IsNativeEnvironment変数がtrueに設定されているため、メッセージをそのウィンドウコンソールに投稿するときに、IDEを混乱させる必要があります。もし、以前にtrueに設定しました。

IDEは、ネイティブコンパイラがネイティブ64ビットマシンで使用されていることを認識し、IDEからネイティブコンパイラが選択されたときに、この変数を適切な値に自動的に設定する必要があります。Aこの問題にパッチを適用するために、単純な修正は適用されていません。解決策：プロンプトから自分で行うか、Microsoftから最新のIDE=を購入して問題を修正してください。

したがって、Microsoftの実際のウィザードは、主にコマンドラインから作業する開発者です。そして、先のとがった帽子をかぶって隅に座っている他の開発者は、Apple=）から雇われたに違いなく、機能よりも外見に関心がありました。

IDEの目的は、コーディングを単純にすることであり、コマンドラインからテキストエディタとMakefileを使用するよりも複雑ではありません。

0
Henry Garcia