24
votes

I am compiling Openssl library that I need to use in python script. I am using Visual Studio 2015 Developer Command Prompt. My machine is Windows 7 64-bit.

When I type the command: nmake -f ms\ntdll.mak

I get this error:

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.

I searched and several solutions for similar problem suggest changing the project platform from the project settings. I do not have VS project. I am running all these commands just to compile the OpenSSL library. I am using the VS command.

5
I had the same problem and resolved it by choosing "VS2015 x64 Native Tools Command Prompt" instead of "Developer Command Prompt for VS2015". Try it on clean version of sources (without previous build output).C0DEF52

5 Answers

29
votes

I ran into the same issue - just with VS2013.

There are 2 approaches which I came across which may or may not be helpful in your case:

THE FIRST APPROACH

(May only be relevant for versions VS2013 and above)

Open the 'VS2015 x64 Native Tools Command Prompt' and execute the command there.

 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' 

Both tools can be found under the folder:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\Shortcuts

THE SECOND APPROACH

(May only be relevant for versions prior to VS2013)

In the Developer Command Prompt for VS2015 you can change the compiler target platform by running the following command

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

"C:\Program Files (x86)\Microsoft Visual Studio [VS Version]\VC\vcvarsall.bat [Target Platform]"

For VS 2017

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat [Target Platform]"

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
7
votes

This error means that tmp32dll\uplink.obj is a 32-bit binary whereas the linker expected it to be 64-bit as it's targeting 64-bit.

Looks like you need to re-compile it as 64-bit, or just perform a rebuild-all (or delete all *.obj or even the whole binary output directory)

This can happen if the build process is interrupted, then you change the target platform, and then you repeat the build process in an incremental manner. 32-bits don't mix with 64-bits, so it's either completely one way or the other.

1
votes

This error comes up because a specific component in the build is being compiled as an x86 binary instead of x64 (the target machine's architecture) - basically you're giving the linker a square puzzle piece and telling it to fit into a circular hole.

In your case:

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.

You look at the name of the obj file that is causing the error: uplink.obj, so you look at uplink.cpp (or uplink.asm or uplink.whatever) and inspect how it's being compiled. Usually all that stuff is automated in VS but sometimes there are special build steps that were added in by the developer. Inspect the custom, pre- and post- build events to see if a x86 tool is being used to assemble it.

In my case, I was trying to compile 7zip in x64 using visual studio 8 and everything was compiling except for the assembly macros (asm), which were compiling in x86 and breaking the build process. I found that VS was trying to use ml.exe to compile them instead of ml64.exe by looking at the asm's property sheet. In my case changed the call to ml64.exe to get rid of this error (I also had to modify the asm files to be 64bit only by getting rid of all the x86 code but that's another story).

0
votes

If using cl in VS2019, just make sure you are compiling with the right VS native tools

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat"

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars32.bat"
0
votes

I use corflags from VS command prompt to change machine type

https://docs.microsoft.com/en-us/dotnet/framework/tools/corflags-exe-corflags-conversion-tool

Change Machine Type: corflags d:\abc.exe /32BITREQ- Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.6.1055.0 Copyright (c) Microsoft Corporation. All rights reserved.

Verify using corflags:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise>corflags d:\abc.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.6.1055.0 Copyright (c) Microsoft Corporation. All rights reserved.

Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 0x1 ILONLY : 1 32BITREQ : 0 32BITPREF : 0 Signed : 0