linking problem: fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

Question

Im trying to run sample app from wxFreeChart library. After compilation on linking there is an error:

wxcode_msw28d_freechart.lib(wxfreechart_lib_xydataset.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

I tried to switch linker option\advanced\target machine to MachineX64 but it doesnt work.

Im using visual studio 2008, any suggestion ?

thanks for help

Can you describe "...it doesn't work." with a few more words, please? — Frank Bollack, May 17 '10 at 14:02
If you use CMake, generate the build files at the x64 command prompt of Visual Studio. — phoad, Dec 29 '13 at 07:37
This is usually due to one of the combinations of Configurations and Platforms being different from the others due to a missed update, or it not being set correctly for any of the combos in the first place. Basically, your program is trying to use an `x86` library in an `x64` module due to either a bad or missing reference 95% of the time when you see an error like this. — kayleeFrye_onDeck, Jun 18 '19 at 21:23

score 33 · Answer 1 · answered May 17 '10 at 15:44

33

The error is explicit, you are trying to link libraries that were compiled with different CPU targets. An executable image can only contain pure x86 (32-bit) or pure x64 (64-bit) code. Mixing is not possible.

You change the target CPU by creating a new configuration for the project, only changing the linker setting isn't enough. Build + Configuration Manager, Active solution platform combo on upper right, choose New and select x64. That creates a new configuration with several modified project settings, most importantly the compiler that will be used.

Beware that prior to VS2010, the 64-bit compilers are not installed by default. If you don't see x64 in the platform combo then you'll need to re-run setup.exe and turn on the option to install the 64-bit compilers. Then also re-run any service pack installer you may have applied.

A possible approach with less pain points is to use the 32-bit version of the library.

answered May 17 '10 at 15:44

Hans Passant

922,412
146
1,693
2,536

its logical but I compiled this libraries on windows using makefile with (I think) default settings witch 32 bit architecture. – gruber May 17 '10 at 16:34
Hmm, avoid making assumptions when you get errors you cannot explain. – Hans Passant May 17 '10 at 16:41
I explained my error, You dont know the answer then dont answer – gruber May 18 '10 at 08:54
10

I explained the reason for this error. If you don't like answers then don't ask. – Hans Passant Dec 10 '13 at 08:33

score 18 · Answer 2 · edited Nov 26 '18 at 21:04

18

I bumped into this too and found a solution.

First on how I got into this problem. I have a project which builds in x86. Then I used the Configuration Manager to add x64, and I hit this problem.

By looking at BuildLog.htm carefully, I saw both of these listed as linker options:

/MACHINE:X64  
/machine:X86

I could not find anywhere in the Property Pages dialog where I could change this, so I opened up the .vcproj file and looked for the appropriate line and changed it to:

AdditionalOptions=" /STACK:10000000 /machine:x64 /debug"

and problem solved.

edited Nov 26 '18 at 21:04

LoneWanderer

3,058
1
23
41

answered Nov 18 '11 at 22:09

l00g33k

181
1
2

4

This answer helped me find a solution in my case where a very similar thing was happening on a different project which I was trying to convert from 32 to 64 bit. Turns out I'd missed converting an explicit /machine:X86 setting in the Additional Options to /machine:x64 – Roger Attrill Mar 25 '12 at 14:55
Worked for me too. With the method mentioned by `Hans Passant`, you might need to set some dependencies and properties again (that you set earlier). – Annie Dec 17 '12 at 14:13
7

btw, the "AdditionalOptions" can be found in the GUI under Linker / Command Line / Additional Options – Oliver Zendel Aug 08 '13 at 14:54

score 6 · Answer 3 · answered Jan 19 '14 at 14:19

6

Go to project properties-> configuration properties -> Librarian Set Target Machine to MachineX64 (/MACHINE:X64)

answered Jan 19 '14 at 14:19

Joseph

1,716
3
24
42

rogerdpack · Answer 4 · 2015-12-23T19:40:10.850

In my case it appears it was because I had "copied settings" from a 32-bit to a new configuration (64 bit) and it hadn't updated the libraries. Odd.

1>MSVCRTD.lib(ti_inst.obj) : fatal error LNK1112: module machine type ‘X86’ conflicts with target machine type ‘x64’

this meant “your properties -> VC++ Directories -> Library Directories” is pointing to a directory that has 32 bit libs built in it. Fix somehow!

In my case http://social.msdn.microsoft.com/Forums/ar/vcgeneral/thread/c747cd6f-32be-4159-b9d3-d2e33d2bab55

ref: http://betterlogic.com/roger/2012/02/visual-studio-2010-express-64-bit-woe

score 2 · Answer 5 · answered May 13 '14 at 21:00

Since the problem is due to the difference in compilation and target machine specifications (x86 & x64) Follow the steps below:

Open the C++ project that you want to configure.
Choose the Configuration Manager button to open the Configuration Manager dialog box.
In the Active Solution Platform drop-down list, select the option to open the New Solution Platform dialog box.
In the Type or select the new platform drop-down list, select a 64-bit platform.

This solved my problem.

score 1 · Answer 6 · answered May 24 '12 at 23:02

I know this is a bit old, but I thought I would provide another tip. In my situation, I inherited this application that I had to maintain. The VS2008 project came with the same string in C/C++->OutputFIles->"ObjectFIleName" and "Program Database File Name" (for both platforms Win32 and x64). So when I built Win32 platform, it built fine, but when I tried to build x64, I got the error:

\Debug64\Objects\common.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

Obviously, both patforms were storing common.obj at the same location, so when I tried to build x64, the linker took the existing object file, which was x86.

To fix I just replaced the existing string with the macro "$(IntDir)\" for x64 (no quotes), and made sure that the macro resolved to the correct path, as in the rest of the projects. That solved my problem.

score 1 · Answer 7 · answered Dec 23 '10 at 02:39

1

Try changing every occurence of .\Release into .\x64\Release in the x64 properties. At least this worked for me...

answered Dec 23 '10 at 02:39

Thomas

11
1

score 0 · Answer 8 · answered Aug 30 '12 at 02:44

An update to i00g's and Thomas' answers, this time for VS2012 (some names have changed). After copying x86 settings over into an x64 target with the configuration manager, you'll have the problem for the same reason as was the case earlier (lib targets aren't correct in the x64 config). Open your .vcxproj (text editor) and replace MachineX86 with MachineX64 where appropriate. (I still haven't found where this is on the property sheets....) This only seems to be necessary with static libs.

score 0 · Answer 9 · answered Apr 04 '13 at 09:22

before going for the step "compile -DIPLIB=NONE filename.cxx" take the path of VIsual Studio installation upto the vcvarsall batch file and change the configuration as shown below.

*C:\apps\MVS9\VC\vcvarsall.bat x86_amd64*

now next step should be

compile -64bit -DIPLIB=none filename.cxx

this solved the problem for me

score 0 · Answer 10 · answered Jul 08 '15 at 22:56

Thanks for the answers guys. My problem was that I changed a x64 solution in Visual Studio to 32 bit in the Configuration Manager only. I ended up just creating a new solution as 32 bit and then copying my C++ code and this error was gone. I think l00g33k and RogerAttrill's suggestions may have been the solution, but mine worked, too.

score 0 · Answer 11 · edited Aug 19 '16 at 03:20

Recently,I also encountered this problem. That's because I used qt(x64) in vs win32. If you want to use qt application x64, you could choose vs x64--as the above. If you want to use win32 and perhaps you haven't,you need to download qt(32bit),then correctly set your enviroment, such as the lib directory, etc.(note: maybe you are is old set in x64(other version), if you convert your win32 or x64 into another, Additional Dependencies includes the old directory!)

score 0 · Answer 12 · answered Jan 29 '17 at 08:21

This problem has nothing to do with the linker, so modifying it's setting won't affect the outcome. You're getting this because I assume you're trying to target x86 but for one reason or another wxcode_msw28d_freechart.lib is being built as an x64 file.

Try looking at wxcode_msw28d_freechart.lib and whatever source code it derives from. Your problem is happening there. See if there are some special build steps that are using the wrong set of tools (x64 instead of x86).

score 0 · Answer 13 · answered Nov 26 '18 at 20:05

0

building on these answers - i also had to modify an X86 reference under Librarian -> Command Line -> Additional Options (for the x64 Platform)

answered Nov 26 '18 at 20:05

Kevin Afanasiff

1

linking problem: fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

13 Answers13

Linked

Related