Re: X64) .zip

0 views
Skip to first unread message
Message has been deleted

Giovanna Qiu

unread,
Jul 9, 2024, 3:40:32 AM7/9/24
to luosniperac

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.

x64) .zip


Download https://shoxet.com/2yLzKW



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.

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:

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.

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.

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.

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

Is it possible to generate both win32 and x64 platforms inside these configurations, or do I need to create separate configurations as a workaround in Introjucer? I.e. create a Debug32 and a Debug64 configuration? Just wondering how other people usually set this up?

So inside the Debug config, I'd like to be able to switch between win32 and x64 builds. This is easy to set up manually, but Introjucer cannot do it. Instead, you're forced to create separate configurations, i.e. one Debug32 and one Debug64. But this doesn't really work smoothly either, because you get win32 and x64 targets inside each of the Debug32 and Debug64 configurations, and in the Debug32 config these are both actually 32bit, while in the Debug64 configuration these are both x64. Confusing! =)

So really, the only way that currently works well right now is to go into the configuration manager in Visual Studio and manually add the x64 target each time I have re-generated the Introjucer project. It's a bit of a pity.

This is actually pretty close to working already. What happens in Visual Studio is that you get the proper combobox where you can choose "Win32" or "x64" within one single "Debug" configuration. And when you build the x64 version, VS automatically places all object files under "./x64/Debug" rather than under "./Debug".

The workaround for this right now is to to set a custom Binary Location to "./Builds/VisualStudio2013/x64/Debug" in Introjucer on the x64 version of the Debug configuration, and a similar thing on the x64 Release configuration. So what should be "fixed" in Introjucer in my opinion is just a different Default Binary Location on x64 builds!

So I tried again the "natural way" to solve this is Introjucer, by creating two configurations with the same name: "Debug" and "Debug". One is set to 32-bit and one is set to x64. [...] However, the output binary is always placed under "./Debug"

You can rename the configuration to "Debug64" (it's the first setting called "Name"). Then the folder under which the output binary is placed will also be named "Debug64", and Visual Studio won't be confused anymore.

The point of the OP was that we actually wanted the Debug config to be just one, in which to discern 32 or 64-bit using the setting provided by Visual Studio for the Architecture. This in contrast to having two configurations, "Debug" and "Debug 64", each having only one "relevant" architecture.

If you want both architectures, the way Visual Studio works is that you select a configuration (Debug or Release) and a platform (Win32 or x64). So I'd expect an option in IntroJucer to creating both 32-bit and 64-bit architectures from one configuration (Debug or Release).

7fc3f7cf58
Reply all
Reply to author
Forward
0 new messages