I am trying to compile a existing CMake project using Cuda v8.0 that I found online. To do that, I use CMake GUI version. (I am currently running Windows 10, with Visual Studio 2017). The "Configure" step always givs me the following error message:
No CMAKE_CUDA_COMPILER could be found.
I have cuda 8.0 installed (altogether with other Cuda versions that I removed from my path), CuDNN also in my path. And I expect at some points to generate Visual studio project files that I could then use to compile the project...
What could cause that error?
EDIT
Upon request, I uploaded the CMakeOutput.log there : https://framabin.org/?c532b10d2a4aef54#NkJZItfUfPwMP6BHCiP5DhQS40duM4AhsKR+bWHN0tE=
Alright! With #raul-laasner help, I think I have the solution of my problems!
The first one was indeed that my Cuda version was not correctly identified. And I am not sure at this stage that one was found at all. My environment variables where probably ignored also. I had to specify the CMAKE_CUDA_COMPILER option to "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v8.0/bin/nvcc.exe".
Then, the problem was that I was using a too recent version of Visual Studio. For starters, Cuda v8.0 is not compatible with Visual Studio 2017: Cuda 8.0 with Visual Studio 2017. But even with the most recent version of Cuda, my Visual Studio is too recent. Meaning: NVIDIA lags behind when it comes to the Visual Studio versions... And now, Microsoft plans to update the _MSC_VER on most of the upgrade. Thus, I had two choices:
Downgrade Visual Studio to a compatible version.
Use more recent version of Cuda (9.2) and modify the c:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.h to change the upper limit of the _MSC_VER verification.
By doing the second option, I managed to configure and compile the project. I am not sure though that I won't have later problems with this "hacky" way. But at least, I've been on a further step!
For me, this issue was caused by nvcc(x64 version) doesn't support x86 platform and was fixed by specifying the platform for cmake:
$build> cmake .. -G"Visual Studio 15 2017 Win64"
Related
I am getting this error while compiling my Fortran code in VS Studio:
warning #31001: The dll for reading and writing the pdb (for example, mspdb110.dll) could not be found on your path.
I also looked to change the Base Platform Toolset in Project Properties, but in VS 2019 IDE I couldn't find this option to edit it.
I am using Intel Compiler 2021. I have also tried upgrading my VS Studio to latest version but the problem persists.
Please tell how to fix this.
This message is saying that your Visual Studio is misconfigured. Make sure that you have the "Desktop Development for C++" and "Windows 10 SDK" components of Visual Studio installed (see https://www.intel.com/content/www/us/en/developer/articles/guide/installing-microsoft-visual-studio-2019-for-use-with-intel-compilers.html) You may need to uninstall both the Intel compiler and Visual Studio, then reinstall.
I want to develop a program using CUDA but I am getting lost by install instructions on NVidia's site.
So here is what I have:
Windows 10 laptop with a NVidia GPU GeForce GTX 870M
(both OS and GPU driver are up to date)
Visual Studio 2017, Version 15.8 (also up to date) _MS_VER=1915
On this webpage, I found out that my GPU is CUDA enabled (good news) with "Compute capability" 3.0. What does it mean?
I know that CUDA versions are sensitive to the version of Visual Studio used, so
my question is simple:
what version of CUDA should I download and install? and can I build and run programs with my version of Visual Studio?
As far as I know, no version of the CUDA Toolkit currently supports Visual Studio 15.8. The latest CUDA 9.2 supposedly supports up to Visual Studio 15.6. Note that the issue of Visual Studio support really only concerns the NVCC compiler and Visual Studio Integration. There's nothing preventing you from, e.g., using the CUDA Driver API with whatever compiler you wish (including the latest version of VS).
One way around these issues used to be to put your CUDA code into a separate static library, build that with the VS 2015 compilers, and link it to the main project which could be built using VS 2017.
Make sure you have selected the VC++ 2015.3 v14.00 (v140) toolset for desktop package in Visual Studio Installer:
You can then switch the toolset to use for each project in Project Properties > General:
Unfortunately, I've recently encountered some issues with linking binaries built with VS 2015 to binaries built with the VS 2017 15.8 compilers, so that path might no longer work (seemed to be related to the new "Just My Code Debugging" feature). But then, binary compatibility across compiler versions was never really something to rely on in the first place…
Another solution would be to downgrade your Visual Studio to 15.6.
The compute capability of a device basically tells you what generation of GPU architecture you're dealing with and which features you can rely on. Or in the words of the CUDA Programming Guide:
The compute capability of a device is represented by a version number, also sometimes called its "SM version". This version number identifies the features supported by the GPU hardware and is used by applications at runtime to determine which hardware features and/or instructions are available on the present GPU.
More details on individual compute capabilities/architectures can be found, e.g., here.
I am currently having issues with Visual Studios 2017 enterprise edition not being able to generate / compile code for UWP projects using CMake,
the Error:
- A Windows Store component with CMake requires both the Windows Desktop SDK
as well as the Windows Store '10.0' SDK. Please make sure that you have
both installed
I have tracked down the issue over a period of time searching it seems that the version of CMake visual studio is using cant properly find Windows 10 SDK or Windows Desktop SDK, i tried to exchange the version of cmake VS2017 is using for a newer version e.g. ( I tried both 3.8 and 3.9 ) both worked to a certain extent until post a parse error in the output for cmake target info extraction.
i found the reason for that is because VS2017 is using a custom version of CMake - 3.7.20170106-gd3236-dirty-MSVC_2
does anyone have a work around to get UWP projects to work with VS 2017 CMake.
It seemed that it's a known issue.
The 3.7.2 version of CMake bundled with Visual Studio 2017 (latest update) cannot on its own find the Visual Studio 2017 build tools. Using CMake 3.8.1 (current CMake release), the tools can be found no problem.
You could see more detailed information from here: Visual Studio 2017 CMake Build Tools Bug
So, please try to use the CMake 3.8
I was drawn crazy this several days to make ifort work in my windows Os. Everytime I installed Ms visual studio firstly and then installed ifort as suggested, I could not find ifort when I was trying to build in the visual studio. What's more, if I ignore the visual studio and solely install ifort, the complier will complain during compiling compland throw me error message like
could not find 'link'
I do numerous searching for the solution but none works. Some suggest I can adjust the parallel studio setting, but I didn't find parallel in the ifort folder.
intel visual fortran demand windows development environment
Could not find link when solely install ifort
You're using a VERY old version. But this version does include a Visual Studio environment. If you have a commercial or academic license, go back to the Intel Registration Center and download the installer that says "Includes Microsoft Visual Studio Shell" (doesn't have _novsshell, _ia32 or _intel64 in the filename).
It would be better, of course, if you were to use a more current version.
I'm running into problems generating a Visual Studio 2010 Express 64 bit project through CMake. I installed VS2010 Express first, then the Windows SDK 7.1 in order to be able to build 64 bit apps and then tried to compile my CMake project.
I do not remember this to be that difficult with 2008 Express, but with 2010 I fail again and again. 2010 searches per default for 7.0a SDK which is shipped with it. The express version seems to ship a reduced 32 bit version, which is located under
.../Program Files(X86)/Microsoft SDKs/Windows/7.0a
Windows SDK 7.1 64bit will be installed per default under
.../Program Files/Microsoft SDKs/Windows/7.0
In VS 2010 Express the platform SDK can be changed on a per-project-map basis and if I do so the inherited path macros surprisingly point to the correct SDK. The problem now is, that CMake is not happy about me screwing around in the project files by myself. Thus, it always resets the Platform SDK entry to the default value, which will make the Windows SDK point to 7.0a and result in complaints about missing 64 bit libs.
I now see two possibilities to resolve this:
Find a way to really integrate the 7.1 SDK into VS2010 Express, just like with VS2008. VS2008 searches the registry for the tag 'CurrentInstallFolder' in the Windows SDKs entry, and you can change this entry to point to another SDK.
Find a way to tell CMake (2.8.1) to set the correct Platform SDK in the project. No plan how to do this...
I would appreciate any help. 2010 is somewhat mandatory unfortunately, I personally cannot get used to it at all...
Ok, updating to the latest CMake (2.8.12) resolved this, CMake now detects the 7.1 SDK and sets it in the project files.
Edit: The toolset can be chosen in a CMake file via the CMAKE_GENERATOR_TOOLSET flag