Как разрешить конфликты типа модуля "X86" с типом целевого устройства "x64" Visual Studio

Я собираю библиотеку Openssl, которую мне нужно использовать в скрипте Python. Я использую командную строку разработчика Visual Studio 2015. Моя машина Windows 7 64-разрядная.

Когда я nmake -f ms\ntdll.mak команду: nmake -f ms\ntdll.mak

Я получаю эту ошибку:

tmp32dll\uplink.obj : fatal error LNK1112: module machine type 'X86' conflicts w
ith target machine type 'x64'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0
\VC\BIN\amd64_arm\link.EXE"' : return code '0x458'
Stop.

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

Ответ 1

Я столкнулся с той же проблемой - только с VS2013.

Есть 2 подхода, с которыми я сталкивался, которые могут или не могут быть полезны в вашем случае:

ПЕРВЫЙ ПОДХОД

(Может относиться только к версиям VS2013 и выше)

Откройте "Командная строка собственных инструментов VS2015 x64" и выполните команду там.

 Note:
 If you get the opposite message:
 module machine type 'x64' conflicts with target machine type 'x86' 
 then you should open the 'VS2015 x86 Native Tools Command Prompt'

Оба инструмента можно найти в папке:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\Ярлыки

ВТОРОЙ ПОДХОД

(Может относиться только к версиям до VS2013)

В командной строке разработчика для VS2015 вы можете изменить целевую платформу компилятора, выполнив следующую команду

"C:\Program Files (x86)\Microsoft Visual Studio 15.0\VC\vcvarsall.bat x64"

"C:\Program Files (x86)\Microsoft Visual Studio [версия VS]\VC\vcvarsall.bat [Целевая платформа]"

Для VS 2017

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat [Целевая платформа]"

Note:
VS Version: 10.0|11.0|12.0|15.0|... 
Target Platform: x86|amd64|x64|arm|x86_arm|x86_amd64|amd64_x86|amd64_arm|amd64_x86
*leaving the target platform empty will default to x86

Ответ 2

Эта ошибка означает, что tmp32dll\uplink.obj является 32-битным двоичным tmp32dll\uplink.obj тогда как компоновщик ожидает, что он будет 64-битным, поскольку он нацеливается на 64-битный.

Похоже, вам нужно перекомпилировать его как 64-разрядную версию или просто выполнить команду rebuild-all (или удалить все *.obj или даже весь каталог двоичного вывода)

Это может произойти, если процесс сборки прерван, затем вы измените целевую платформу, а затем повторите процесс сборки поэтапно. 32-биты не смешиваются с 64-битными, так что это либо полностью так или иначе.

Ответ 3

Эта ошибка возникает из-за того, что конкретный компонент в сборке компилируется как двоичный файл x86 вместо x64 (архитектура целевой машины) - в основном вы даете компоновщику квадратную кусочку головоломки и говорите ему, чтобы он входил в круглое отверстие.

В твоем случае:

tmp32dll\uplink.obj : fatal error LNK1112: module machine type 'X86' conflicts w
ith target machine type 'x64'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0
\VC\BIN\amd64_arm\link.EXE"' : return code '0x458'
Stop.

Вы смотрите на имя файла obj, вызывающего ошибку: uplink.obj, поэтому вы смотрите на uplink.cpp (или uplink.asm или uplink.whatever) и проверяете, как он компилируется. Обычно все это происходит автоматически в VS, но иногда есть специальные шаги сборки, которые были добавлены разработчиком. Осмотрите пользовательские события pre- и post-, чтобы узнать, используется ли инструмент x86 для его сборки.

В моем случае я пытался скомпилировать 7zip в x64 с помощью visual studio 8, и все было компилировано, за исключением макросов сборки (asm), которые компилировались в x86 и прерывали процесс сборки. Я обнаружил, что VS пытался использовать ml.exe для компиляции их вместо ml64.exe, просмотрев лист свойств asm. В моем случае был изменен вызов ml64.exe, чтобы избавиться от этой ошибки (мне также пришлось изменить файлы asm на 64 бит, только избавившись от всего кода x86, но это другая история).