cuda-api-wrappers: cannot find -lcudadevrt -lcudart_static

$ mkdir build && cd build

$ cmake ..

$ make
...
[ 13%] Linking CXX executable examples/bin/unified_addressing
/usr/bin/x86_64-linux-gnu-ld: cannot find -lcudadevrt
/usr/bin/x86_64-linux-gnu-ld: cannot find -lcudart_static
collect2: error: ld returned 1 exit status
CMakeFiles/unified_addressing.dir/build.make:84: recipe for target 'examples/bin/unified_addressing' failed

$ ls ~/.local/cuda-9.0/lib64 | grep cuda
libcudadevrt.a
libcudart.so
libcudart.so.9.0
libcudart.so.9.0.176
libcudart_static.a

I’m using CUDA 9.0 and g++ 6.5.0. Looks like it cannot find my customized CUDA lib folder. Any solutions for this?

Also, some similar warnings are given when compiling:

[ 11%] Building CXX object CMakeFiles/unified_addressing.dir/examples/by_runtime_api_module/unified_addressing.cpp.o                                  
In file included from /home/user/cuda-api-wrappers/src/cuda/api/device.hpp:13:0,                                                                       
                 from /home/user/cuda-api-wrappers/examples/by_runtime_api_module/unified_addressing.cpp:15:                                           
/home/user/cuda-api-wrappers/src/cuda/api/device_properties.hpp:99:13: warning: In the GNU C Library, "major" is defined                               
 by <sys/sysmacros.h>. For historical compatibility, it is                                                                                            
 currently defined by <sys/types.h> as well, but we plan to                                                                                           
 remove this soon. To use "major", include <sys/sysmacros.h>                                                                                          
 directly. If you did not intend to use a system-defined macro                                                                                        
 "major", you should undefine it after including <sys/types.h>.                                                                                       
  unsigned as_combined_number() const noexcept { return major() * 10 + minor_; }                                                                      
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 19 (19 by maintainers)

Commits related to this issue

Regards #106. * Reverting to the use of the `FindCUDA.cmake` module to have the wrappers library also depend on the CUDA runtime libraries. This is an ugly hack! — committed to eyalroz/cuda-api-wrappers by deleted user 5 years ago
Regards #106. * Reverting to the use of the `FindCUDA.cmake` module to have the wrappers library also depend on the CUDA runtime libraries. This is an ugly hack! — committed to eyalroz/cuda-api-wrappers by deleted user 5 years ago
Merge pull request #108 from eyalroz/use-find-cuda Using FindCUDA again... which fixes #106 . — committed to eyalroz/cuda-api-wrappers by deleted user 5 years ago

Most upvoted comments

This actually is an issue. The problem is that CMake does not register cuda-api-wrappers as a target, which uses CUDA at all. This issues occures for all CXX executables, which link against cuda-api-wrappers. A consistent solution would look like:

find_package(cuda_runtime REQUIRED)
...
target_link_libraries(cuda-api-wrappers cuda_runtime::cuda_runtime)
...

This would require to write a CMake-Find-Module for the CUDA runtime libraries. This is also related to what I mentioned in:

https://github.com/eyalroz/cuda-api-wrappers/pull/102#discussion_r267714918

To my mind CMake should provide a way to distinguish the CUDA language and the CUDA libraries. But that can take a while, thus I can write a find module first.

I did not detect this issue, because I use custom CUDA installations and always set LIBRARY_PATH appropriately.

PS: A hacky solution would be to rename profiling.cpp to profiling.cu

codecircuit on Apr 20, 2019

@zingdle: I’ve followed @codecircuit 's suggestion and replaced the head of the use-find-cuda branch. Please check it out and see whether that lets the example programs build on docker and your system. You can also inspect the changes as PR #108 (it was updated with my recent forced-push).

eyalroz on Apr 22, 2019

I refer to current HEAD of branch use-find-cuda (52260ae28ee6b3818cbbcb938d816b0b762e48f6). To resolve the build issues with the examples we need to remove the dynamic link from the examples:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9c16f49..9d60881 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -112,7 +112,7 @@ target_link_libraries(${PROJECT_NAME} ${CUDA_LIBRARIES})
 # Examples / Tests
 # -----------------------
 
-link_libraries(${CMAKE_CUDA_IMPLICIT_LINK_LIBRARIES} cuda-api-wrappers)
+link_libraries(cuda-api-wrappers)
 
 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "examples/bin")
 add_executable(vectorAdd EXCLUDE_FROM_ALL examples/modified_cuda_samples/vectorAdd/vectorAdd.cu)

@eyalroz So up to now I think we are fine and do not need a find module for the CUDA runtime libraries, right? At least as long as findCUDA is supported.

codecircuit on Apr 22, 2019

@codecircuit So, is the find_package() you suggested intended for a project which uses cuda-api-wrappers or are you suggesting that it be used in cuda-api-wrappers’ CMakeLists.txt?

Also - indeed, cuda-api-wrappers does not use the CUDA libraries for its compilation; it’s more of an INTERFACE requirement, I’d say. I’m reminded of @DeveloperPaul123 's PR #80 , in which he added the CUDA libraries as an explicit dependency on WIN32. I suppose your suggestion is a sort of a generalization of that.

Finally - isn’t it problematic to run find_package(cuda_runtime REQUIRED) on a post-3.8 CMake? Shouldn’t we just be using some internal variables somehow?

eyalroz on Apr 20, 2019

I can take a look at this. @zingdle Can you give exact steps how to reproduce your issue within the Docker container?

codecircuit on Apr 19, 2019