Re: [CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017

[Andrea Borsic]

Hi,

Thanks for your pointers, problem solved.

I have upgraded to CMake 3.9.1 (I don't think this matters though) and I 
switched to using the new CUDA CMake support as at your point 3). I am 
also using CUDA 9 RC which supports VS2017 (I was testing under CUDA 8 / 
CUDA 9 earlier, but just forgot to mention this). Now all builds 
successfully.


I am attaching the updated CMakeLists.txt file for the record.

Thanks, Best Regards,

Andrea



On 8/10/2017 4:28 PM, Robert Maynard wrote:

So you are going to have two issues.

1. The FindCUDA module has not been updated to handle VS2017. The
issue is that the VCInstallDir variable now returns a different
relative path to the compiler than it previously did. If you can
determine the new logic a patch fixing this behavior be great.

2. It doesn't look like CUDA 8.0 supports VS2017 (
http://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html#system-requirements
).

3. You could also look at using the new CMake 3.9 cuda support (
https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/
).

On Thu, Aug 10, 2017 at 5:49 AM, Andrea Borsic <abor...@gmail.com> wrote:

Hi All,

I am working on this platform:

Windows 10 64bit
Visual Studio 2015 Community Edition
Visual Studio 2017 Community Edition
CUDA 8.0
CMake 3.9

I am in the middle of switching from VS2015 to VS2017, but CUDA projects
fail to properly compile under VS2017 as the compiler/linker fail to find
tools on the path setup by CMake. I believe this is bug/incompatibly of the
CMake FindCUDA module with VS2017.

To reproduce the problem I am attaching a tiny project

main.cu is a minimal CUDA example from the web
CMakeLists.txt is a CMake file that leads to a successful build under VS2015
and unsuccessful under VS2017
Output VS2015 is the output from building the project under VS2015 (all
targets built OK)
Output VS2017 is the output from building the project under VS2015 (1 target
OK one target fails)

I have noticed also that oddly under VS2017 an "x64" and "main.dir"
directories are created outside the build dir, and at the level of the
source directory.

I thought of reporting this to the list, and any help is welcome,

Thank you and Best Regards,

Andrea


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


#include 

//
// Nearly minimal CUDA example.
// Compile with:
//
// nvcc -o example example.cu
//

#define N 1000

//
// A function marked __global__
// runs on the GPU but can be called from
// the CPU.
//
// This function multiplies the elements of an array
// of ints by 2.
//
// The entire computation can be thought of as running
// with one thread per array element with blockIdx.x
// identifying the thread.
//
// The comparison i>>(da, db);

//
// Copy output array from GPU back to CPU.
//
cudaMemcpy(hb, db, N*sizeof(int), cudaMemcpyDeviceToHost);

for (int i = 0; i<N; ++i) {
printf("%d\n", hb[i]);
}

//
// Free up the arrays on the GPU.
//
cudaFree(da);
cudaFree(db);

return 0;
}# minimal example based on 
https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/

cmake_minimum_required(VERSION 3.9 FATAL_ERROR) # this is required for the new 
CUDA support module

project (TestProject LANGUAGES CXX CUDA)

add_executable(TestExecutable main.cu)

target_compile_features(TestExecutable PUBLIC cxx_std_11)

set_target_properties(TestExecutable PROPERTIES CUDA_SEPARABLE_COMPILATION ON)

SET(CUDA_NVCC_FLAGS "-arch=sm_35" CACHE STRING "nvcc flags" FORCE)




-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017

[Andrea Borsic]

Hi All,

I am working on this platform:

 * Windows 10 64bit
 * Visual Studio 2015 Community Edition
 * Visual Studio 2017 Community Edition
 * CUDA 8.0
 * CMake 3.9

I am in the middle of switching from VS2015 to VS2017, but CUDA projects 
fail to properly compile under VS2017 as the compiler/linker fail to 
find tools on the path setup by CMake. I believe this is 
bug/incompatibly of the CMake FindCUDA module with VS2017.


To reproduce the problem I am attaching a tiny project

 * main.cu is a minimal CUDA example from the web
 * CMakeLists.txt is a CMake file that leads to a successful build
   under VS2015 and unsuccessful under VS2017
 * Output VS2015 is the output from building the project under VS2015
   (all targets built OK)
 * Output VS2017 is the output from building the project under VS2015
   (1 target OK one target fails)

I have noticed also that oddly under VS2017 an "x64" and "main.dir" 
directories are created outside the build dir, and at the level of the 
source directory.


I thought of reporting this to the list, and any help is welcome,

Thank you and Best Regards,

Andrea

PROJECT (Test)

CMAKE_MINIMUM_REQUIRED(VERSION 3.1)

FIND_PACKAGE(CUDA REQUIRED)

SET(CUDA_NVCC_FLAGS "-arch=sm_35" CACHE STRING "nvcc flags" FORCE)

CUDA_ADD_EXECUTABLE(main main.cu)


#include 

//
// Nearly minimal CUDA example.
// Compile with:
//
// nvcc -o example example.cu
//

#define N 1000

//
// A function marked __global__
// runs on the GPU but can be called from
// the CPU.
//
// This function multiplies the elements of an array
// of ints by 2.
//
// The entire computation can be thought of as running
// with one thread per array element with blockIdx.x
// identifying the thread.
//
// The comparison i>>(da, db);

//
// Copy output array from GPU back to CPU.
//
cudaMemcpy(hb, db, N*sizeof(int), cudaMemcpyDeviceToHost);

for (int i = 0; i-- Build started: Project: ZERO_CHECK, Configuration: Debug x64 --
1>  Checking Build System
1>  CMake does not need to re-run because 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp is up-to-date.
2>-- Build started: Project: main, Configuration: Debug x64 --
2>  Building NVCC (Device) object 
CMakeFiles/main.dir/Debug/main_generated_main.cu.obj
2>  main.cu
2>  main.cu
2>  Building Custom Rule D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test 
Cmake VS2017/src/CMakeLists.txt
2>  CMake is re-running because 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp is out-of-date.
2>the file 'D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/main.dir/main_generated_main.cu.obj.depend'
2>is newer than 'D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp.depend'
2>result='-1'
2>  -- Configuring done
2>  -- Generating done
2>  -- Build files have been written to: 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8
2> Creating library D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test 
Cmake VS2017/build_win64_vs2015_cuda8/Debug/main.lib and object 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/Debug/main.exp
2>  main.vcxproj -> D:\Dropbox\NES_Projects_Technical\Active\HP-EIT\Test Cmake 
VS2017\build_win64_vs2015_cuda8\Debug\main.exe
2>  main.vcxproj -> D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/Debug/main.pdb (Full PDB)
3>-- Skipped Build: Project: ALL_BUILD, Configuration: Debug x64 --
3>Project not selected to build for this solution configuration 
== Build: 2 succeeded, 0 failed, 0 up-to-date, 1 skipped ==1>-- Build started: Project: ZERO_CHECK, Configuration: Debug x64 --
1>Checking Build System
1>CMake does not need to re-run because 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2017_cuda8/CMakeFiles/generate.stamp is up-to-date.
2>-- Build started: Project: main, Configuration: Debug x64 --
2>Building NVCC (Device) object 
CMakeFiles/main.dir/Debug/main_generated_main.cu.obj
2>Failed to run C:/Program Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/bin (The system cannot find the file specified.
2>
2>).
2>CMake Error at main_generated_main.cu.obj.Debug.cmake:222 (message):
2>  Error generating D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake
2>  
VS2017/build_win64_vs2017_cuda8/CMakeFiles/main.dir//Debug/main_generated_main.cu.obj
2>
2>
2>C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5):
 error MSB6006: 

[CMake] How to specify that a target link library is shared ?

[Andrea Borsic]

Dear All,

I am a recent user of CMake, and I cannot figure out how to tell CMake 
that a TARGET_LINK_LIBRARY is shared. I am working under Windows Xp with 
MS VisualStudio 2008, and the following is my CMakeLists file:


PROJECT(Triangle)

ADD_LIBRARY(triangle_lib SHARED triangle.c)

ADD_EXECUTABLE(tricall tricall.c)

TARGET_LINK_LIBRARIES(tricall triangle_lib)

With the first target I am building a shared library 'triangle_lib.dll' 
and with the second target I'd like to build an executable 'tricall' 
that links to such library.


Linking fails, as VS 2008 is looking for the static library 
'triangle_lib.lib'. I have been searching the forums, and came across an 
example: TARGET_LINK_LIBRARIES(tricall SHARED triangle_lib), but then 
the linker looks for SHARED.lib, so 'SHARED' in not interpreted as a 
keyword but as the name of a library.


Does anybody know how I should specify that I am linking against a 
shared library ?


Thanks in advance for your advice,

Best Regards,

Andrea
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to specify that a target link library is shared ?

[Andrea Borsic]

Hi All,

Yes it is the .def file that defines the import/exports, but the linking 
stage fails before taking care of these aspects: it looks for 
triagle_lib.lib which is not there and stops before considering symbol 
resolutions.


Thanks for your help, I will be reading all the emails that came in,

Regards,

Andrea



Joshua L. Blocher wrote:

Isn't the def files the defines the export symbols.

Boudewijn Rempt wrote:

On Tue, 7 Oct 2008, Andrea Borsic wrote:

 


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake