26

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.

GEOCHET
  • 21,119
  • 15
  • 74
  • 98
user2192774
  • 3,807
  • 17
  • 47
  • 62
  • 4
    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). – dmitry1100 Mar 15 '16 at 15:23
  • Possible duplicate of [error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'](http://stackoverflow.com/questions/14235014/error-lnk1112-module-machine-type-x64-conflicts-with-target-machine-type-x86) – m7913d Apr 22 '17 at 14:20

5 Answers5

33

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
Merav Kochavi
  • 4,223
  • 2
  • 32
  • 37
  • 2
    Thanks, launching an x86 32-bit Visual Studio shell resolved my issues compiling 32-bit openssl on Windows 10. The error message was: crypto\aes\aes_cfb.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' – Jay Taylor May 29 '17 at 18:16
  • 2
    For VS 2017, vcvarsall.bat can be found in "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build" –  Sep 29 '17 at 22:52
  • @TrevorSeward Adding your comment to the answer, Thanks! – Merav Kochavi Oct 01 '17 at 06:06
  • 1
    I had this same problem after installing the Microsoft Visual C++ Compiler for Python from [here](https://www.microsoft.com/en-us/download/details.aspx?id=44266). I found my vcvarsall.bat usually found here (C:\Users\$User\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0)and ran it with the input "x64" and viola ! now everything builds fine for 64bit. – Some Guy Jun 21 '18 at 14:30
  • Thanks a lot for the VS 2017 explanation ! – Saitama Sep 26 '19 at 09:25
  • tools are directly here `C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2017\Visual Studio Tools\VC` – Mohammad Kanan Jan 06 '21 at 23:25
7

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.

V-R
  • 1,309
  • 16
  • 32
  • Thanks for your help. Can you please help me with "how" to: 1) "re-compile uplink.obj as 64-bit, or" 2) "just perform a rebuild-all (or delete all *.obj or even the whole binary output directory)". I am newbie to such thing. – user2192774 Jul 25 '15 at 03:54
  • Looks like nmake /b is the option to rebuild. nmake /? will show you all the options. But if I were you I would try to download an existing binary distribution of openssl instead of trying to build it by myself. – V-R Jul 25 '15 at 13:42
  • I have to build it my self because I will replace some files and re-compile. Binaries do not serve my need. – user2192774 Jul 25 '15 at 20:18
  • could you please point how can I perform rebuild-all or delete the binary output directory? where is the binary output directory supposed to be? – user2192774 Jul 26 '15 at 15:42
  • i don't know, it really depends on the openssl build system. often however the directory will be named debug,release,bin,x86,x32,x64,win32,win64 or a combination thereof – V-R Jul 26 '15 at 17:26
  • 2
    I couldn't figure out how to make openssl do a clean, but I deleted all of the *.obj files by hand and it seemed to do the trick. – MatrixManAtYrService Oct 24 '16 at 15:43
  • Yea, much easier to just delete the build file or folder by manually – Theko Lekena Jun 29 '19 at 15:55
2

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).

thebunnyrules
  • 1,520
  • 15
  • 22
0

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"
Ombre
  • 21
  • 4
0

I use corflags from VS command prompt to change machine type

https://learn.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

tomcat
  • 1,798
  • 2
  • 11
  • 14