How do I force Visual Studio 2010 to use x64? - c++

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.

Related

Linking libpqxx from Visual Studio 2015 on Windows 10

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

MSVC 2013 loading x86 system libraries in x64 build

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.

'atltime.h error 32-bit compilation verses 64-bit compilation

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?

Tracing LNK1112 error in Visual Studio 2012

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.

How do I start a new CUDA project in Visual Studio 2008?

This is an incredibly basic question, but how do I start a new CUDA project in Visual Studio 2008? I have found tons and tons of documentation about CUDA related matters, but nothing about how to start a new project. I am working with Windows 7 x64 Visual Studio 2008 C++. I would really like to find some sort of really really basic Hello World app to just get a basic program compiling and running.
Edit:
I tried your steps Tom. I setup a console app. I then deleted the default .cpp it drops in and copied over the three files from the template project just to have something to compile. When I compile that, template_gold.cpp complained about not having stdafx.h included, so i included that. Now the build fails with this:
1>------ Build started: Project: CUDASandbox, Configuration: Debug x64 ------
1>Compiling...
1>template_gold.cpp
1>Linking...
1>LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup
1>D:\Stuff\Programming\Visual Studio 2008\Projects\CUDASandbox\x64\Debug\CUDASandbox.exe : fatal error LNK1120: 1 unresolved externals
1>Build log was saved at "file://d:\Stuff\Programming\Visual Studio 2008\Projects\CUDASandbox\CUDASandbox\x64\Debug\BuildLog.htm"
1>CUDASandbox - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
NOTE With the release of version 3.2 of the CUDA Toolkit, NVIDIA now includes the rules file with the Toolkit as opposed to the SDK. Therefore I've split this answer into two halves, use the correct instructions for your version of the Toolkit.
NOTE These instructions are valid for Visual Studio 2005 and 2008. For Visual Studio 2010 see this answer.
CUDA TOOLKIT 3.2 and later
I recommend using the NvCudaRuntimeApi.rules file (or NvCudaDriverApi.rules if using the driver API) provided by NVIDIA, this is released with the toolkit and supports the latest compiler flags in a friendly manner. Personally I would advise against using the VS wizard, but only because I really don't think you need it.
The rules file (installed into the Program Files\Microsoft Visual Studio 9.0\VC\VCProjectDefaults directory) "teaches" Visual Studio how to compile and link any .cu files in your project into your application.
Create a new project using the standard MS wizards (e.g. an empty console project)
Implement your host (serial) code in .c or .cpp files
Implement your wrappers and kernels in .cu files
Add the NvCudaRuntimeApi.rules (right click on the project, Custom Build Rules, tick the relevant box), see note 1
Add the CUDA runtime library (right click on the project and choose Properties, then in Linker -> General add $(CUDA_PATH)\lib\$(PlatformName) to the Additional Library Directories and in Linker -> Input add cudart.lib to the Additional Dependencies), see notes [2] and [3]
Optionally add the CUDA include files to the search path, required if you include any CUDA files in your .cpp files (as opposed to .cu files) (right click on the project and choose Properties, then in C/C++ -> General add $(CUDA_PATH)\include to the Additional Include Directories), see note [3]
Then just build your project and the .cu files will be compiled to .obj and added to the link automatically
Some other tips:
Change the code generation to use statically loaded C runtime to match the CUDA runtime; right click on the project and choose Properties, then in C/C++ -> Code Generation change the Runtime Library to /MT (or /MTd for debug, in which case you will need to mirror this in Runtime API -> Host -> Runtime Library), see note [4]
Enable syntax highlighting using the usertype.dat file included with the SDK, see the readme.txt in <sdk_install_dir>\C\doc\syntax_highlighting\visual_studio_8
I'd also recommend enabling Intellisense support with the following registry entry (replace 9.0 with 8.0 for VS2005 instead of VS2008):
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Languages\Language Services\C/C++]
"NCB Default C/C++ Extensions"=".cpp;.cxx;.c;.cc;.h;.hh;.hxx;.hpp;.inl;.tlh;.tli;.cu;.cuh;.cl"
Incidentally I would advocate avoiding cutil if possible, instead roll your own checking. Cutil is not supported by NVIDIA, it's just used to try to keep the examples in the SDK focussed on the actual program and algorithm design and avoid repeating the same things in every example (e.g. command line parsing). If you write your own then you will have much better control and will know what is happening. For example, the cutilSafeCall wrapper calls exit() if the function fails - a real application (as opposed to a sample) should probably handle the failure more elegantly!
CUDA TOOLKIT 3.1 and earlier
I would use the Cuda.rules file provided by NVIDIA with the SDK, this is released alongside the toolkit and supports the latest compiler flags in a friendly manner. Personally I would advise against using the VS wizard, but only because I really don't think you need it.
The rules file (in the C\common directory of the SDK) "teaches" Visual Studio how to compile and link any .cu files in your project into your application.
Create a new project using the standard MS wizards (e.g. an empty console project)
Implement your host (serial) code in .c or .cpp files
Implement your wrappers and kernels in .cu files
Add the Cuda.rules (right click on the project, Custom Build Rules, browse for the rules file and ensure it is ticked)
Add the CUDA runtime library (right click on the project and choose Properties, then in Linker -> General add $(CUDA_LIB_PATH) to the Additional Library Directories and in Linker -> Input add cudart.lib to the Additional Dependencies), see note [2] below
Optionally add the CUDA include files to the search path, required if you include any CUDA files in your .cpp files (as opposed to .cu files) (right click on the project and choose Properties, then in C/C++ -> General add $(CUDA_INC_PATH) to the Additional Include Directories)
Then just build your project and the .cu files will be compiled to .obj and added to the link automatically
Some other tips:
Change the code generation to use statically loaded C runtime to match the CUDA runtime, right click on the project and choose Properties, then in C/C++ -> Code Generation change the Runtime Library to /MT (or /MTd for debug, in which case you will need to mirror this in CUDA Build Rule -> Hybrid CUDA/C++ Options), see note [4]
Enable syntax highlighting using the usertype.dat file included with the SDK, see the readme.txt in <sdk_install_dir>\C\doc\syntax_highlighting\visual_studio_8
I'd also recommend enabling Intellisense support with the following registry entry (replace 9.0 with 8.0 for VS2005 instead of VS2008):
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Languages\Language Services\C/C++]
"NCB Default C/C++ Extensions"=".cpp;.cxx;.c;.cc;.h;.hh;.hxx;.hpp;.inl;.tlh;.tli;.cu;.cuh;.cl"
Incidentally I would advocate avoiding cutil if possible, instead roll your own checking. Cutil is not supported by NVIDIA, it's just used to try to keep the examples in the SDK focussed on the actual program and algorithm design and avoid repeating the same things in every example (e.g. command line parsing). If you write your own then you will have much better control and will know what is happening. For example, the cutilSafeCall wrapper calls exit() if the function fails - a real application (as opposed to a sample) should probably handle the failure more elegantly!
NOTE
You can also use a Toolkit-version-specific rules fule e.g. NvCudaRuntimeApi.v3.2.rules. This means that instead of looking for the CUDA Toolkit in %CUDA_PATH% it will look in %CUDA_PATH_V3_2%, which in turn means that you can have multiple versions of the CUDA Toolkit installed on your system and different projects can target different versions. See also note [3].
The rules file cannot modify the C/C++ compilation and linker settings, since it is simply adding compilation settings for the CUDA code. Therefore you need to do this step manually. Remember to do it for all configurations!
If you want to stabilise on a specific CUDA Toolkit version then you should replace CUDA_PATH with CUDA_PATH_V3_2. See also note 1.
Having mismatched version of the C runtime can cause a variety of problems; in particular if you have any errors regarding LIBCMT (e.g. LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs) or multiply defined symbols for standard library functions, then this should be your first suspect.
What a great question!! For all the CUDA documentation out there, this is something that I've always thought was an obvious omission... In fact, I'm really glad I found this post, because after using CUDA for quite a while, I still hadn't found an official, correct way to get VS to produce a CUDA program from scratch.
When I've needed to start a new CUDA program, I've always just copied and modified the "template" example from the SDK directory. This may not be exactly what you're looking for, because it doesn't start fresh, but it is a quick way to get a CUDA-capable project working in VS with all the correct project/file names...
Make a copy of the "template" example from the SDK, and rename the directory -- the only necessary contents in the directory are source code and VS .sln and .vcproj files
Rename both .sln and .vcproj files
Open the .sln file in a text editor, and rename the Project variable and .vcproj filename in the 3rd line of the file
Open the .vcproj file in a text editor, and rename the Name and RootNamespace variables in the first few lines of the file
Open the project with VS, and open the Property Pages (right click on the project name in the solution explorer pane, select "Properties")
Change the Output File name in the Property Pages (under Configuration Properties -> Linker -> General) ... Before I change the filename, I select "All Configurations" from the Configuration pull-down and "x64" from the Platform pull-down, since I'm on a 64-bit system
Change the Program Database File name in the Property Pages (under Configuration Properties -> Linker -> Debugging) ... Before I change the filename, I select "Debug" and "x64" in the pull-downs.
Install CUDA VS wizard. It will setup VS and add CUDA Project to the "new project" menu.
Make sure that you have x64 compiler installed (must be checked during VS install).
Check if you have x64 libs, includes, nvcc dir and in the search path.
Create new project using CUDA template.
Change project type to x64 and CUDA setting to Native (if you have nv cuda-enabled card) or emulation otherwise.
The template will create custom build rules that compile .cu files with nvcc and other files with default compiler.
if, vs is trying to compile .cu files with C/C++ compiler, click on that file in solution explorer and disable compilation for that files (red dot on file's icon)
Additional info about installing CUDA wizard on VS2008 can be found here and here
[edit]
If you don't want to use wizard you have to setup CUDA lib/include/nvcc paths manually and add custom build rules to each new CUDA program. For additional info how to do it take a look at Tom's Answer.
You may want to take a look at this guide: http://www.programmerfish.com/how-to-run-cuda-on-visual-studio-2008-vs08/