Как заставить Visual Studio использовать встроенную привязку amd64

Как я могу заставить Visual Studio 2012 использовать встроенную привязку amd64, а не кросс-компилятор x86_amd64 по умолчанию?

Я создаю большую библиотеку, которая заставляет компоновщик исчерпывать память при выполнении всей оптимизации программы и генерации кода времени.

Я нашел две более старые сообщения (здесь и здесь), задав этот же вопрос, но пока ответов нет, Microsoft предоставляет документацию о том, как указать toolchain в командной строке, но не в среде IDE.

Ответ 1

Перед запуском 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

как внедрить PreferredToolArchitecture в проект в VS13

Ответ 2

Существует еще один способ принудительного использования 64-разрядного компоновщика для каждого проекта для Visual Studio 2013. Отредактируйте файл .vcxproj и вставьте следующее после строки <Import...Microsoft.Cpp.Defaults:

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

Ответ 3

Если ваша цель - использовать родную среду, а не специально amd64_x86, вы можете установить свойство UseNativeEnvironment в файле проекта:

<PropertyGroup>
  <UseNativeEnvironment>true</UseNativeEnvironment>
</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

Ответ 4

Я знаю, что это довольно старая статья, но она по-прежнему актуальна для VS 2017. Здесь у вас также есть переменная окружения PreferredToolArchitecture, а настройка "build in" в IDE недоступна.

Однако вы можете легко интегрировать это в проект по базе проекта, чтобы вы всегда могли выбрать, какую архитектуру инструмента использовать. Может быть, это полезно для некоторых. Сделай это:

Перейдите в Property Manager и создайте новый лист свойств, например с именем "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, включите новую таблицу свойств в проект в диспетчере свойств. И для тех, кто не должен просто не включать это. Это.

НТН

Редактировать: кажется, к сожалению, это не надежно! Смотрите ниже комментарии. Я был бы очень признателен, если бы MS подключил этот параметр к какому-либо элементу графического интерфейса и заставил бы его работать согласованно...

Ответ 5

У меня похожая проблема с использованием Visual Studio 2010 на XP 64 SP2. Если я установил исполняемый каталог VC++ в папку amd64 (собственную папку x64) в качестве первого в пути поиска, то я получил ошибку TRK0002… Неверное значение дескриптора.

Но если я установлю _IsNativeEnvironment = true в командной строке Visual Studio 2010 и запустю ide из командной строки, как было опубликовано ранее, ошибка исчезнет. По-видимому, 32-битная среда IDE GUI получает информацию от 64-битного процесса и ожидает информацию от 32-битного процесса, такого как x86\cl.exe или x86_64\cl.exe.

В сценарии, в котором вы хотите скомпилировать исполняемый бит IA64 и используете компилятор x86_ia64\cl.exe. Поскольку вы используете 32-разрядный кросс-компилятор и для переменной _IsNativeEnvironment установлено значение true, это должно расстраивать IDE при публикации сообщений в консольных окнах. Установите _IsNativeEnvironment = false, если вы ранее установили его в значение true.

Среда IDE должна определить, что на собственном 64-разрядном компьютере использовался собственный компилятор, и должна автоматически установить для этой переменной соответствующее значение, когда собственный компилятор был выбран из среды IDE. Простое исправление никогда не применялось для исправления этой проблемы. Решение. Сделайте это самостоятельно из командной строки или купите последнюю версию IDE от Microsoft, чтобы решить проблему.

Итак, настоящие волшебники в Microsoft - это разработчики, которые работают в основном из командной строки. А другие разработчики, которые носят заостренные шляпы и сидят в углу, должны были быть наняты Apple и больше заботились о внешнем виде, чем о функциональности.

Вся цель IDE - сделать кодирование простым, не более сложным, чем использование текстового редактора и Makefile из командной строки.