CUDA 9.0 compilation issues

[cmpute]

I don't know whether some one has encountered any problems when using CUDA 9 with VS2017, but I actually haven't successfully built packages with cuda feature onec. Many packages which contain CUDA support haven't completely finished CUDA 9 support.

Here are messages of four major kinds of errors:

1. Error generating XXXXX.cu.obj: This might occurred when the package source haven't implemented VS2017 support, since the compiler path is changed from VS2015 to VS2017.
2. Host compiler targets unsupported OS: MSVC compiler is (so new that) no supported by CUDA, as CUDA: Host compiler targets unsupported OS. #2791 stated.
3. unsupported Microsoft Visual Studio version! Only the versions 2012, 2013, 2015 and 2017 are supported: MSVC compiler is not in proper range given by CUDA. Edit <CUDA-Path>/include/crt/host_config.h can temporarily fix this.
4. expression must have a constant value: If you have the these issues above fixed, you will meet this problem when using CUDA 9 with VS2017. This seems to be an API corruption. Rolling back to VS version older than 2017 15.4 or using toolset v140 may be able to fix this. Two ways to use v140 in VS2017:
   • Define -T v140 in vcpkg_configure_cmake
   • Use vsvarall.bat to set shell environment to use v140, and then use vcpkg to build. (For ports using ninja)

Related issues in other repositories are collected here:

1. Windows 10 with CUDA 9 compile errors fireice-uk/xmr-stak#91
2. Can't compile with CUDA 9.1 fireice-uk/xmr-stak#606
3. CUDA 9.0 does not work with the latest VS 2017 update
4. CUDA 9 failed to support the latest Visual Studio 2017 version 15.5

I open this issue here to track the avaliability of CUDA support, and provide solution for ones who has faced similar problems.

[cmpute]

Actually, use vsvarall.bat proved to be ineffective because of the cmd_execute_clean in vcpkg codes. I'm now wondering is there any method to pass custom environment variable into the actual build environment?

[cenit]

Even latest CUDA release does not seem to support 14.12 compiler, so it's not so easy to have it working with the latest VS 15.5 update... unfortunately.
Older versions of VS 2017 have v141 toolset which is now compatible after all, like the older v140. The problem is that in the meantime the toolset has been upgraded another time!

[jasjuang]

Unfortunately it will only work with VS2017 15.4

See https://devtalk.nvidia.com/default/topic/1027299/cuda-setup-and-installation/cuda-9-failed-to-support-the-latest-visual-studio-2017-version-15-5/

The download link is here https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017

[cenit]

it's better to install older toolchain with newer vs ;)
in the manual install inside the vs installer (also the latest one, 15.5.5) you can find v141 and v14.11, working with cuda

[cmpute]

Actually I used v14.10 and v14.11, both failed to build for pcl and cuda with CUDA 9.0 and CUDA 9.1.

How about downgrade to use v140? I ran vcpkg install opencv[cuda] just now with v140 but failed. However, I directly opened the generated solution file and built using VS2017 15.6, it succeeded.....

[ras0219-msft]

We don't currently have a way to pass multiple toolsets into a build, which could explain the difference.

Edit <CUDA-Path>/include/crt/host_config.h can temporarily fix this.

I want to see what we can do around this -- since we have quite a bit of control when building libraries inside vcpkg, we can likely work around any issues that occur due to the newer compiler+libraries (such as using macros to disable parts of the STL that are problematic for that particular build).

[cmpute]

@ras0219-msft If the modification can be temporarily done and restore automatically, then it would be great!

Besides, I don't mentioned this issue for multiple toolsets in one build, but how I'm able to use vcpkg to specify the buildchain I used in the whole build process? When I look through the issues, I only found VCPKG_PLATFORM_TOOLSET may be able to do this. But this variable behaves beyond my expectation, it sets the generator version instead of compiler version. I'm unable to use v140 toolset within VS2017 with this variable. However, vsvarall.bat is expected to set the buildchain within the shell environment.

[ras0219-msft]

set(VCPKG_PLATFORM_TOOLSET v140) inside the triplet file should run the correct vsvarsall.bat -- if it doesn't, that's a bug!

Adding --debug to the install command line will print more diagnostic information (including the vsvars we're running!), and you can use vcpkg env --triplet <triplet> to get the cmd prompt we build libraries inside.

[cmpute]

I made a mistake that I thought VCPKG_PLATFORM_TOOLSET can be set in portfile. I set in triplet file and now it works! Thanks! But the issue should be open until CUDA 9 can be compiled with VS2017

[JackBoosY]

Hi everyone, Thanks for reporting this issue!
I can't reproduce this issue on the latest version, maybe someone has fixed it.
Please install cuda_10.1.168_425.25_win10.exe, update vcpkg and rebuild cuda.

Thanks.