I'm using CMake 3.16, with a CMakeLists.txt file specifying a minimum CMake version of 3.9. In my file, I have:
find_package(CUDA 8.0 REQUIRED)
find_package(OpenCL REQUIRED)
# etc. etc.
target_link_libraries(my_executable
PRIVATE
cuda # The NVIDIA CUDA driver API
${CUDA_LIBRARIES}
OpenCL::OpenCL
)
Now, in the CMake generation phase, I get the error:
CMake Warning at CMakeLists.txt:44 (add_executable):
Cannot generate a safe runtime search path for target my_executable because
files in some directories may conflict with libraries in implicit
directories:
runtime library [libOpenCL.so.1] in /usr/lib64 may be hidden by files in:
/usr/local/cuda/lib64
Some of these libraries may not be found correctly.
Now, I do want the libOpenCL.so.1 from the CUDA directories; and building does produce an executable with the correct dependency. How can I tell CMake that this masking is ok, and not have it print the warning message?
Note: Working with CUDA in CMake has changed a lot over the 3.x series of releases. So whatever was happening before 3.8 is irrelevant, and also things changed significantly in 3.17 with a few more non-trivial changes afterwards. Answers about pre-3.8 and 3.17-or-later are, well, fine - but not what I need.
I know this doesn't answer your question precisely, but as of CMake 3.17+, the CUDA OpenCL libraries are loaded by the FindCUDAToolkit module. It is used like so:
cmake_minimum_required(VERSION 3.17)
project(my_proj LANGUAGES C CXX CUDA)
find_package(CUDAToolkit 8.0 REQUIRED)
# ...
target_link_libraries(
my_executable
PRIVATE
CUDA::cuda_driver
CUDA::cudart
CUDA::OpenCL
)
I hope this answer will help other readers who are using up-to-date CMake, because whatever answer works on 3.9 will not be quite as nice.
As #AlexReinking suggests in a comment, you can avoid this warning by giving CMake a (strong) hint regarding which OpenCL location you want to use. Before running CMake, set your OpenCL_ROOT environment variable to /usr/local/cuda; with a CMake version higher than 3.12, the find_package() command will use that variable, preferring to locate OpenCL there if possible - and not warn you about the alternative location.
Related
I want to use uWebSockets(UWS) in my C++ project to transfer images over the network. The setup will be running on multiple operating systems, so the best way of creating the build files seemed like using CMake.
However, I am new to CMake and having a hard time building UWS. I don't understand how to start working with the official repository on Windows 10, so I found another repository that includes a CMakeFiles.txt file and some of the dependencies (openssl, zlib, libuv, but it doesn't include uSockets for some reason). The root CMakeFiles.txt includes:
[...]
find_package(OpenSSL REQUIRED)
find_package(ZLIB REQUIRED)
find_path(LIBUV_INCLUDE_DIR uv.h)
find_library(LIBUV_LIBRARY NAMES uv uv1)
[...]
It looks straightforward, but when I try to run mkdir build && cd build; cmake .., it cannot find OpenSSL. Here is the error message it spits out:
[...]
[cmake] Could not find a package configuration file provided by "OpenSSL" with any
[cmake] of the following names:
[cmake]
[cmake] OpenSSLConfig.cmake
[cmake] openssl-config.cmake
[...]
The above error message suggests that I need to set up a config file for each of these libraries. Yet, if I understand the find_package docs correctly, the command itself searches the library in various locations under the root folder. What kind of a folder structure does the find_package need in order to work?
More generally, am I wasting my time with this alternative repo? Is there a better way of using UWS with Windows 10? The official repo has a question about how to use it on Windows but I don't understand how that's an answer to the question. It only points to this page where it says any specific build systems will not officially be supported.
Any help would be appreciated.
Importing dependencies with add_subdirectory seems like a good way around this. When I ran cmake, I was receiving LNK2019 Error. I realized the following code snippet I found online was causing the problem, and the system works when I delete it.
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS_DEBUG "${CMAKE_EXE_LINKER_FLAGS_DEBUG} /NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:msvcrt.lib")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:WINDOWS")
endif()
I have a project based on cuda10.1, qt5. And I use cmake to manage the compilation. However the same cmake script work fine in Windows, but in Linux, I got error "Unknown option 'fPIC'" when compiling .cu files. I look into makefile, then find there is a extra error flag "-fPIC" passed to nvcc compiler. Spending hours of testing, I find linking qt5 libraries will automatically pass extra fPIC flag which causes this error. I don't know this is bug or feature of cmake?
cmake_minimum_required(VERSION 3.10)
project(PyPhysLeo LANGUAGES CXX CUDA)
find_package(Qt5 COMPONENTS Core Widgets)
if(Qt5_FOUND)
message("Find QT5")
link_libraries(Qt5::Widgets Qt5::Core Qt5::Gui)
endif()
set(CMAKE_CXX_STANDARD 14 CACHE STRING "CXX STANDARD VERSION 11,14,17")
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
set(CMAKE_CUDA_SEPARABLE_COMPILATION ON CACHE BOOL "DEFAULT SET SEPERABLE COMPILATION MODE")
set(CMAKE_CUDA_FLAGS "${CMAKE_CUDA_FLAGS} -arch=sm_60")
include_directories(${CMAKE_CUDA_TOOLKIT_INCLUDE})
add_executable(test test.cu)
if you try above cmake script with any sample cuda code, you will get "nvcc fatal" error because it doesn't recognize fPIC flag.
It is a problem with qt5.cmake. Thanks to Robert Crovella for commenting (see above) about the related information gitlab.kitware.com/cmake/cmake/issues/16915. There is no perfect solution so far. But...
One solution, if you can separate your project into a library and an executable sub-projects, then you can cleanly avoid the issue altogether. Try to put all the .cu files in a library sub-project and only link qt5 in an executable sub-project. This is one way to avoid this problem.
Otherwise, you can try to modify the variable defined by qt5.cmake, for that solution please refer to cmake issue 16915.
In CMake version 3.8, native support for CUDA as a language was introduced. When a project has CUDA as one of its languages, CMake will proceed to locate CUDA (e.g. it locates the nvcc binary).
As long as you only compile CUDA code - this is enough. But what if you want to compile a C++ target in that project? The CUDA includes are not -I'ed automatically, and CMakeCache.txt does not seem to contain the CUDA include path anywhere.
Do I actually have to run something find_package(CUDA 9.0 REQUIRED) even when CMake itself has already located CUDA? Or - can I obtain the include directory some other way?
The include directories, which are used by the compiler set by CMAKE_CUDA_COMPILER, can be retrieved from the CMake variable CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES.
For getting the libraries, the best way is probably to use find_library() in combination with CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES.
Example:
cmake_minimum_required(VERSION 3.9)
project(MyProject VERSION 1.0)
enable_language(CUDA)
find_library(CUDART_LIBRARY cudart ${CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES})
add_executable(
binary_linking_to_cudart
my_cpp_file_using_cudart.cpp
)
target_include_directories(
binary_linking_to_cudart
PRIVATE
${CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES}
)
target_link_libraries(
binary_linking_to_cudart
${CUDART_LIBRARY}
)
This issue is also discussed on the CMake bug tracker: Provide target libraries for cuda libraries.
Update: CMake 3.17.0 adds FindCUDAToolkit
Instead of doing find_library() manually, the best way as of CMake 3.17.0 would be to use the CUDAToolkit module.
find_package(CUDAToolkit)
add_executable(
binary_linking_to_cudart
my_cpp_file_using_cudart.cpp
)
target_link_libraries(binary_linking_to_cudart PRIVATE CUDA::cudart)
For support with earlier CMake versions, you can ship the CUDATookit module file with minimal changes in your repository.
These days, with CMake 3.18 and later, you can get most of what you need by examining the targets provided by find_package(CUDAToolkit) - which you do need even if CUDA has located the CUDA compiler. But actually, you may just depend on one of those targets and avoid using the include directories directly.
PS - If you happen to use cuda-api-wrappers (e.g. via find_package(cuda-api-wrappers)), it will take care of the dependencies for you.
In CMake version 3.8, native support for CUDA as a language was introduced. When a project has CUDA as one of its languages, CMake will proceed to locate CUDA (e.g. it locates the nvcc binary).
As long as you only compile CUDA code - this is enough. But what if you want to compile a C++ target in that project? The CUDA includes are not -I'ed automatically, and CMakeCache.txt does not seem to contain the CUDA include path anywhere.
Do I actually have to run something find_package(CUDA 9.0 REQUIRED) even when CMake itself has already located CUDA? Or - can I obtain the include directory some other way?
The include directories, which are used by the compiler set by CMAKE_CUDA_COMPILER, can be retrieved from the CMake variable CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES.
For getting the libraries, the best way is probably to use find_library() in combination with CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES.
Example:
cmake_minimum_required(VERSION 3.9)
project(MyProject VERSION 1.0)
enable_language(CUDA)
find_library(CUDART_LIBRARY cudart ${CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES})
add_executable(
binary_linking_to_cudart
my_cpp_file_using_cudart.cpp
)
target_include_directories(
binary_linking_to_cudart
PRIVATE
${CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES}
)
target_link_libraries(
binary_linking_to_cudart
${CUDART_LIBRARY}
)
This issue is also discussed on the CMake bug tracker: Provide target libraries for cuda libraries.
Update: CMake 3.17.0 adds FindCUDAToolkit
Instead of doing find_library() manually, the best way as of CMake 3.17.0 would be to use the CUDAToolkit module.
find_package(CUDAToolkit)
add_executable(
binary_linking_to_cudart
my_cpp_file_using_cudart.cpp
)
target_link_libraries(binary_linking_to_cudart PRIVATE CUDA::cudart)
For support with earlier CMake versions, you can ship the CUDATookit module file with minimal changes in your repository.
These days, with CMake 3.18 and later, you can get most of what you need by examining the targets provided by find_package(CUDAToolkit) - which you do need even if CUDA has located the CUDA compiler. But actually, you may just depend on one of those targets and avoid using the include directories directly.
PS - If you happen to use cuda-api-wrappers (e.g. via find_package(cuda-api-wrappers)), it will take care of the dependencies for you.
I am using OpenCV with gcc and cmake. And I found a tutorial https://docs.opencv.org/3.4.0/db/df5/tutorial_linux_gcc_cmake.html .In the file CMakeLists.txt, there are some variables such as OpenCV and OpenCV_INCLUDE_DIRS.
cmake_minimum_required(VERSION 3.9)
project(VideoRecord)
set(CMAKE_CXX_STANDARD 11)
find_package(OpenCV REQUIRED)
include_directories(${OpenCV_INCLUDE_DIRS})
add_executable(VideoRecord main.cpp)
target_link_libraries(VideoRecord ${OpenCV_LIBS})
I want to know where to find these variables definition.
EDIT
Thanks #qbranchmaster's answer. I tried to search FindOpenCV.cmake but failed.
First try.
➜ ~ cmake --help-module-list | grep "FindOpen"
FindOpenACC
FindOpenAL
FindOpenCL
FindOpenGL
FindOpenMP
FindOpenSSL
FindOpenSceneGraph
FindOpenThreads
Another try.
➜ / find . "FindOpenCV.cmake"
In addition, my os is osx and I install cmake with brew. I comiple and install OpenCV manually.
These variables are part of the package config script shipping with OpenCV.
Note that find_package is a two-headed beast. The classic mode of operation is finding libraries through find-scripts. This is still the approach being used today for third-party libraries that are not aware of CMake. However, if your dependency is itself being built with CMake, it can provide a package config file instead, which allows for a more powerful mode of operation.
The idea here is that instead of you telling CMake how to find a dependency, the dependency itself tells CMake how clients can find it. This is the approach that is taken by libraries like OpenCV and Qt.
To answer your question, those variables are being set by the package config file in your local OpenCV installation, the template of which can be found in the OpenCV source code under cmake/templates/OpenCVConfig.cmake.in.
They are defined in CMake OpenCV module. CMake has numerous modules that aid in finding various libraries like OpenCV (FindOpenCV.cmake module).
Using this command you can get a list of modules that your CMake supports:
cmake --help-module-list
Some libraries come with their own *.cmake modules which should be installed in some system path. If you are using Ubuntu, your cmake modules should be localised in:
/usr/share/cmake/Modules/
If not, just search system for file FindOpenCV.cmake. In that file you will find these variables.
In general, you get variable names from the documentation or source code of the package you want to find.
Often you can derive the name to put into find_package from the provided FindFoo.cmake module file name, because "Foo" would be the name. The find module is either part of CMake or comes with the third-party library.
If there is no find module, some modules provide FooConfig.cmake files, where "Foo" is again the string to put into find_package.
If you have neither a find nor a config file, you need to find the library by other means, e.g., FindPkgConfig or find_library / find_file.