I have a 32-bit VC++ application, which I have recompiled as 64-bit application as I want to use it on a 64-bit OS.
Code-wise no change is required as it is compatible for both 32-bit and 64-bit.
Hence, I just did 3 changes while (porting) compiling in 64-bit.
1) In VS2008 (drop down menu in the top) I changed from "Win32" to "x64".
2) In the configuration manager, I ensured that the project I'm compiling is changed to "x64".
3) In the project properties --> Linker ->Advanced options-> machine Type :: change the value to MACHINEx64.
Now after having given the background, coming to actual problem when I compile the project in 32-bit mode, it's compiling successfully.
But when I compile the project as x64 by doing the above mentioned changes, it's giving the below error.
fatal error C1083: Cannot open include file: 'atltime.h': No such file or directory
How do I fix this problem? I'm I missing any libraries?
But I used the same settings for linker as in "32bit mode". i.e pointing to the same set of *.lib files. (since all the libraries are statically linked, this application generates only an EXE).
PS: Point to note is that the VS in my system is installed in C:\ProgramFiles(x86) and not in C:\ProgramFiles. So I see that "atltime.h" header file is in
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include"
Is this can be any reason that this header file atltime.h is not recognized while building the code in 64-bit mode?
Thanks in advance.
Have you tried adding the include path to your 64-bit project directory settings?
Related
I've recently decided to try out PostgreSQL as the database platform for some C++ development I'm working on. I decided to use libpqxx as the connection library for my project, and quickly found out this would be an uphill battle to do from VS 2015 on a Windows 10 machine.
After much teeth-gnashing and nail-biting, I have gotten libpqxx to compile on Windows 10.
This leaves me with the following directory structure
Per libpqxx's documentation, I also placed a copy of libpq.dll in my project's executable directory. Please note: I have done this for both debug and release builds, tried to build both, and ended up with the same result.
All the tutorials I've seen seem to indicate that the library can be used after linking it and simply #including pqxx/pqxx, so I set up a small project to do just that. I receive the error:
fatal error C1083: Cannot open include file: 'pqxx/pqxx': No such file or directory
When attempting to build the project. I have also tried this will both debug and release builds, to no avail.
Here is a screenshot of my linker settings.
Does anyone have any suggestions for how I might be able to link and use this library from Visual Studio 2015?
As Sami Kuhmonen pointed out, this was not actually a linker error, but a compiler error. I needed to include an actual header, which Visual Studio needed to be able to find. After adding the correct folder (C:\libpqxx\include in my case) to Visual Studio's "additional include directories" setting under C\C++ -> General per drescherjm's suggestion, the program compiles just fine.
For future reference:
I did also run into unresolved external linker errors after solving the initial issue. This is because you need to make sure to also link to ws2_32.lib and libpq.lib. You also need to copy some other DLL files that libpq also relies on into your libpqxx lib folder. On my system, I believe these were ssleay32.dll, libeay32.dll, and libintl-8.dll. These files reside under the root of the PostgreSQL install. The DLL step is mentioned under libpqxx's INSTALL.txt file, however I believe it stated that the DLLs resided one folder under where I actually found them.
I have also faced same issue. Then I realized that I was building ,my application as a 32bit. I changed the target to x64 and it compiled successfully
First off, I did already check and found this question which is similar to my issue:
fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
The solution there isn't usable though as VS2013 doesn't have the VC++ Directories settings anymore. It looks like those are configured through environment variables now, but I'm not sure how to fix this without borking the 32-bit builds.
====================================
I am working on porting a project from 32-bit to 64-bit code and so I created an x64 platform in my visual studio project. The debug build works fine, but the release build give me this error:
1>MSVCRT.lib(ti_inst.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
Setting the VERBOSE:Lib option, it appears to be trying to find the default system libraries in the x86 paths instead of x64. This pastebin includes the compiler and linker commandlines (yes, this is MACHINE:X64) as well as the VERBOSE:Lib output.
http://pastebin.com/Bqu0udRi
I'd like to know a) how do I fix this, and b) why would this only affect the release build? Looking at the library progress log for the debug build, I can see it is picking up the x64 paths and libraries correctly.
Perhaps it affect only Release build, because you have different properties set in this build configuration or different property sheets attached.
First of all, open Visual Studio, then go to Property Manager and expand Release | x64 configuration. Check if any other .props are placed above the Microsoft.Cpp.x64.user. If yes, check if they do not overwrite include/library directories.
Also compare what .props are attached in Debug | x64 configuration. Maybe some of them are required but not attached in Release?
If all this is fine, verify Microsoft.Cpp.x64.user itself. Go again to Property Manager, right click it and then Properties -> VC++ Directories. Check if Library Directories entry contains something like:
$(VCInstallDir)lib\amd64
$(VCInstallDir)atlmfc\lib\amd64
$(WindowsSDK_LibraryPath_x64)
The above entries are copied from my x64 .props file.
Lastly, switch to Solution Explorer and then check Project Properties - your project may have defined additional local directories, that are missing in this configuration (or shouldn't be present). Simply compare content in Debug and Release configurations.
Hope this helps.
One more thing:
You may also want to check global macros used by Visual Studio (or, to be more precise, what do they expand to). I ran into very serious problem once, after (with no reason) one of standard directory macro was overwritten to wrong value.
Sometimes I getting this error:
fatal error C1007: unrecognized flag '-archVFPv3-D32' in 'p2'
Visual Studio 2013, Windows Store app (c++ and c# projects).
It seems that full rebuild resolve this problem - until next time.
Any ideas?
Thanks
This can also occur when you have changed the compiler and the static libs that you are linking to are compiled using a different compiler. E.g. different versions of MSVC compilers.
I got this problem too. And my mistake was:
1) Using .lib file which compiled how a Debug and i use him in Release mode app
In general, my app was get old .lib with old parameters from error link.
I updated parameter in Configuration Properties -> Linker -> General -> Additional Library Directories and all works at fine.
I have a project that I have been compiling as an x64 project for quite some time, but for various reasons I have to compile it as an x86 project now.
The problem I have run in to is that every time I compile the project I now get a LNK1112 error.
1>Link:
1>
1> Starting pass 1
1>Release\CameraCapture.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
1>
1>Build FAILED.
The file Release\CameraCapture.obj is compiled from a .cpp file that is part of my project.
I have removed every additional .lib dependency in my project just to try to eliminate any possibility that I had missed getting the 32 bit version of any 3rd party libraries. All that is left is the Windows libraries that are added to projects by default.
I want to know is there any way to trace specifically which files are involved with the LNK1112 error? Obviously the CameraCapture.obj is involved, but this file should be x86 and not have any problems. Does anyone have any good tips on how to approach finding the problem I am having?
Some tips for dealing with this sort of problem:
Turn on the linker startup banner so you can see exactly what inputs it is using (or look at the command line in the project properties.
Make sure the project is clean so there aren't any old binaries laying around.
Make sure you have the proper platform type set in your project settings. I'd even go so far as to search for x64 and x86 in the .vcxproj files themselves to make sure you caught everything.
Use dumpbin /HEADERS to check the machine type of the .obj and .lib files going into the linker.
Whenever I create a new project in Visual Studio 2010 and don't set the specific platform (in my case x64) at first, I won't be able to completly change it afterwards.
So I setup everything a need with an external library (compiled as x64) and then press compile it obviously fails since the two platforms do not match.
sfml-graphics-s-d.lib(RenderStates.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
Noticed that I change it to x64 with Build->Configuration-Manager->Active projectplattform->New...->x64. That's the same thing I'd do before doing anything else and it works, but if I do it afterwards I get the linker error:
libcpmtd.lib(uncaught.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
The *.obj file can change from project to project (e.g. cout.obj) and from my understanding Visual Studio picks the x86 standard library and doesn't change it's decision after I've switched the platform.
So for the question: How do I force VS to use the new specified x64 platform - also for the standard library?
Note: Creating a new configuration setup will automatically change the linker setting for the target machine to: MachineX64 (/MACHINE:X64)
Note: Not sure if it's relevant but I'm linking the runtime library statically Multithreaded-Debug (/MTd)
If anyone would ever run into the same problems as I did, he can find the discussion and solution over at the MSDN 'forum'.
OK, I found it, LibraryPath corresponds to Library Directories property in VC++ Directories project property page. That explains what happened, that value is usually inherited so it changes automatically when you create add x64. But since you modified that value it is now local to the project and it simply gets copied when add x64... with all those x86 specific dirs.
I suppose it's simpler and safer to just add that lib dir in Linker\General\Additional Library Directories
Lukas' answer above is correct. However, there may be additional complications.
If changing your Library Directory path is not working, ensure your vcxproj file is not read-only or try editing the paths directly in the vcxproj file.
With the VS Perforce add-in, changing the Library Directories paths and building may not actually save your project file and you won't get a warning that the file was read-only, allowing the build to proceed with the old, incorrect settings.