CMake can not find opencl sdk by NVIDA - c++

I just installed NVIDIA CUDA tool kit to use it for developing the OpenCL application on windows 8.1.
I came across some problems:
1- FinedOpenCl.cmake doesn't work since opencl_dir is not set by the Nvidia tool kit.
cmake file is:
FIND_PACKAGE(OpenCL REQUIRED)
INCLUDE_DIRECTORIES(${OPENCL_INCLUDE_DIR})
and cmake error is:
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find OpenCL (missing: OPENCL_LIBRARY OPENCL_INCLUDE_DIR)
Call Stack (most recent call first):
C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/FindOpenCL.cmake:35 (find_package_handle_standard_args)
CMakeLists.txt:5 (FIND_PACKAGE)
2- There is no cl.hpp for c++ interface.
3- Headers and libraries are on different directories and hence it is difficult to use them with the application.
My questions:
1- Is there anything that I can do to solve them?
2- Is there any option during setup that does the required setting automatically.

Using definitions found here:
http://www.cmake.org/cmake/help/v3.1/module/FindOpenCL.html
Try the below (I did a quick test on Windows 10 Pro and Ubuntu 14.04LTS):
FIND_PACKAGE(OpenCL REQUIRED)
INCLUDE_DIRECTORIES(${OpenCL_INCLUDE_DIRS})
LINK_DIRECTORIES(${OpenCL_LIBRARY})
You may also want to check:
How to add header file path in CMake file

You can run cmake with additional -D options, like:
cmake [some_your_options] -DOpenCL_LIBRARY=/cygdrive/c/cuda/lib -DOpenCL_INCLUDE_DIR=/cygdrive/c/cuda/include [some_your_other_options] .....
So it will see OpenCL such manually specified paths.
Upper example provided for my CygWin64, where in the folder C:\cygdrive I added several symbolic links by mklink for all needed logical drives before, so "c" links to "C:\", "d" links to "D:\" and so on.
My NVidia CUDA install path is really C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.0\, but it is not very handy, so I also maked symlink (mklink /D linkname "path") on C: named "cuda", so /cygdrive/c/cuda/lib is really points to C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.0\lib.
Unix environment emulation on windows and compiling in command promt is very tricky, yes..

There is no standard FindOpenCl.cmake, so I don't know what file you are using, but in my code I search in a bunch of different folders, including these:
$ENV{OPENCL_DIR}
$ENV{NVSDKCOMPUTE_ROOT} # NVIDIA on Windows
$ENV{CUDA_PATH_V6_5}
$ENV{CUDA_PATH}
In addition, I have seen some trouble depending on whether the paths has a final '\' or not - it seems like some kind of bug in CMake, where it fails to automatically handle both situations. So try adding a backslash to your environment variables.
That's a fact - NVIDIA simply doesn't include cl.hpp, but you can download it from Khronos: https://www.khronos.org/registry/cl/api/1.1/cl.hpp.
This should also be handled by the FindOpenCl.cmake - if not, you will have to write your own, or find one that sets up the include and lib variables properly.
Finally, there is no secret option to fix any of these during installation :)

Related

Problem with installing Shark machine learning library

I am Installing Shark machine learning library in my Laptop which its config is :
CPU: CoreI7 10th generation
GPU: Radeon RX640
OS: Windows 10
IDE: Visual studio 2019
according to shark website help, Boost library must be installed before any action .
I got the Boost library boost_1_74_0-msvc-14.2-64 from its boost website. Running the exe makes a folder C:\local\boost_1_74_0
some helps from Youtube says it is enough to install boost and use the addresses belong to this folder and some other helps says you must build it , so I did two ways separately for two kind of installing.
After that , I got the shark library from its official website
or
http://image.diku.dk/shark/sphinx_pages/build/html/rest_sources/downloads/downloads.html
I started to extract it and put it in a source folder and then I made a build folder near it.
I run the CMAKE and put the source address in the source text box and build address in the build text box.
then I made to entries to CMAKE : BOOST_ROOT:C:\local\boost_1_74_0 and BOOST_LIBRARYDIR:C:\local\boost_1_74_0\lib64-msvc-14.2
the I configured it , some messages were in the output page in the CMAKE:
CMake Warning at C:/Program
Files/CMake/share/cmake-3.17/Modules/FindBoost.cmake:1179 (message):
New Boost version may have incorrect or missing dependencies and
imported targets Call Stack (most recent call first): C:/Program
Files/CMake/share/cmake-3.17/Modules/FindBoost.cmake:1303
(_Boost_COMPONENT_DEPENDENCIES) C:/Program
Files/CMake/share/cmake-3.17/Modules/FindBoost.cmake:1904
(_Boost_MISSING_DEPENDENCIES) Test/CMakeLists.txt:11 (find package)
I kept going it because it was just warning and I had put the BOOST address in the CMAKE config
so I generate it via CMAKE and the run the visual studio solution in ADMIN and build the shark.sln but the after a lot of compiling time , the result was : 198 projects FAILED
Visual studio makes these errors after building the shark project:
Error LNK1181 cannot open input file '..\lib\Release\shark.lib'
Error C2668 'shark::size': ambiguous call to overloaded function
Error C3861 'make_iterator_range': identifier not found
these errors are repeated for 230 times in shark project building process
these errors makes me confused and I don't know what to do because when shark.lib is created that building process gets completed and in the middle of building , compiler is looking for what?
another item is shark::size error is not clear for me because all the relations between library files and header files in this project is clear but compiler cannot relate them together and makes error
Boost is a collection of libraries. Some must be built, others are header-only (just #include). Visual Studio is common enough that Boost provides a link to pre-built libraries. You downloaded the correct MSVC 14.2 build for VS2019.
Since Boost is a collection of libraries, sometimes library A needs library B. CMake knows about the dependencies in most Boost versions, but not the newest. So when a project tells CMake it needs Boost library A, CMake will automatically include B as well. If this is the problem with Shark, you'll need to manually add the missing Boost dependencies to CMakeLists.txt.

Compiling with CMake and ITK error

I'm trying to compile some code from here using CMake and ITK but I'm running into an error.
In CMake I select the source folder at /utilities/ITKImageSeriesToVolume and the build folder at /utilities/ITKImageSeriesToVolume/build. This however gives me an error:
CMake Error at CMakeLists.txt:42 (find_package):
By not providing "FindITK.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "ITK", but
CMake did not find one.
Could not find a package configuration file provided by "ITK" with any of
the following names:
ITKConfig.cmake
itk-config.cmake
Add the installation prefix of "ITK" to CMAKE_PREFIX_PATH or set "ITK_DIR"
to a directory containing one of the above files. If "ITK" provides a
separate development package or SDK, be sure it has been installed.
I have tried to set a CMAKE_PREFIX_PATH environment variable that points to the root folder of ITK containing ITKConfig.cmake but get the same error.
Hoping someone can help, thanks in advance.
EDIT: After setting ITK_DIR to the root ITK folder I get:
CMake Error at D:/Apps/InsightToolkit/ITK/ITKConfig.cmake:48 (include):
include could not find load file:
D:/Apps/InsightToolkit/Build/ITKTargets.cmake
Call Stack (most recent call first):
CMakeLists.txt:42 (find_package)
CMake Error at D:/Apps/InsightToolkit/Source/CMake/ITKModuleAPI.cmake:56 (message):
No such module: "ITKDoubleConversion"
Call Stack (most recent call first):
D:/Apps/InsightToolkit/Source/CMake/ITKModuleAPI.cmake:26 (itk_module_load)
D:/Apps/InsightToolkit/Source/CMake/ITKModuleAPI.cmake:84 (_itk_module_config_recurse)
D:/Apps/InsightToolkit/ITK/ITKConfig.cmake:68 (itk_module_config)
CMakeLists.txt:42 (find_package)
It has a simple fix as mentioned in the ERROR
"Add the installation prefix of "ITK" to CMAKE_PREFIX_PATH or set "ITK_DIR"
to a directory containing one of the above files. If "ITK" provides a
separate development package or SDK, be sure it has been installed."
Make sure your point the CMAKE_PREFIX_PATH and ITK to your ITK Build Directory. This is assuming you have already build ITK using Cmake atleast once.
Steps
1) Create ITK source folder.
2) Create ITK build folder.
3) Run CMake and select source and build folders.
4) Select respective compiler, and if there are any compiler issues refer this discussion.
5) Configure and generate cmake.
6) Open the build files in build folder with respective IDE (use .sln file if visual studio compilers are used).
7) Build all once on visual studio.
8) Now for your new project use same steps and point CMAKE_PREFIX_PATH and ITK to your ITK Build Directory.
And everything should work.
Good Luck!!!
Your ITK build seems to be partly broken. Can you try re-building it? If that does not help, see whether ITK_USE_SYSTEM_DOUBLECONVERSION is ON. That means not to build DoubleConversion library which comes with ITK but to use the one already present on the system. If it is not present, you have a problem.
Also, unless ITK_BUILD_DEFAULT_MODULES is ON, you have to specifically turn on each module or module group you want to be compiled. In that case, turn on ITKDoubleConversion, and any additional modules which that code requires.

Cmake finds hdf5 but tries to link against dll on windows

I use find_package(HDF5 COMPONENTS CXX REQUIRED) in my CMAKE script to load the include directories and libraries of HDF5. Cmake tells me
Found HDF5: C:/Program Files/HDF_Group/HDF5/1.10.0/bin/hdf5_cpp.dll (found version "1.10.0") found components: CXX
And generates my visual studio solution.
I also use the library stored in ${HDF5_LIBRARIES} ${HDF5_CXX_LIBRARIES} for my target, but when I try to build it, I get a Linker Error LNK1107 saying that for file hdf5_cpp.dll:
invalid or corrupt file: cannot read at 0x380
which I think is due to the fact that visual studio is trying to directly link against the dll file instead of against the lib file which is in another folder, namely in:
C:\Program Files\HDF_Group\HDF5\1.10.0\lib
Question: Is this a bug in FindHDF or did I configure something wrong?
I have not used hdf5 on windows for some time, but I do recall there being a bug that causes it to link against the dll instead of the lib.
you should manually set (either via the command line cmake -D method, or via the cmake gui)
HDF5_hdf5_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5.lib
HDF5_hdf5_cpp_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5_cpp.lib
etc. - or just
HDF5_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5.lib
HDF5_cpp_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5_cpp.lib
depending on whether you have an older or newer version of FindHDF5 (they change the library var names in newer versions - check the ones used to make sure you get them right - I'm doing this from memory so might have made a mistake)
EDIT:
If the option of manaully specifying the libs is a problem, then there is the option of using FindPackage(HDF5 NO_MODULE) if your hdf5 library was compiled using cmake generated makefilesetc.
When using NO_MODULE, the find package scripts will bypass the findhdf5.cmake script and look for the HDF5Config.cmake or hdf5-config.cmake file that is placed in the relevant subdir of the hdf5 build/install folfer.
This is cross platform friendly and is supported by all newer hdf5 versions - provided they were built using cmake and not ./configure ...

Possible causes for Boost not being found by CMake in certain situations?

I build a C++ project depending on the Boost library using CMake (3.4.1). Host platform is Linux, targets are that host and cross-build Android NDK.
I'm only using Boost header files and I just downloaded/extracted the boost folder (and I don't have a /usr/include/boost directory).
In my CMakeLists.txt file I declare the dependency to Boost like this:
find_package(Boost 1.57 REQUIRED)
And I configure my build like this:
BOOST_ROOT=/path/to/boost cmake ../src
Which actually works as expected for my native build.
When I now configure a build exactly the same way (only specifying some more environment variables and a CMAKE_TOOLCHAIN_FILE) CMake gives me:
BOOST_ROOT=/path/to/boost JAVA_HOME=/bla/bla/bla \
ANDROID_NDK=/bla/bla/bla \
ANDROID_SDK=/bla/bla/bla \
ANT=/usr/bin/ant \
cmake ../src -DCMAKE_TOOLCHAIN_FILE=/bla/bla/android.toolchain.cmake
CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:1247 (message):
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:4 (find_package)
So I believe I did almost the same to build for the Android target but the very same method that finds Boost for the host-build doesn't work here.
I tried to set Boost_DIR, BOOSTROOT and BOOST_INCLUDEDIR all with the same effect. Also I've deleted all content in the build directory before trying anything new.
What can be possible reasons for this behavior? I've already tried to print BOOST_ROOT directly in the FindBoost.cmake script like this:
message("BOOST_ROOT: $ENV{BOOST_ROOT}")
With the expected behavior (writing BOOST_ROOT: /path/to/boost).
Of course I can cheat now and just link the boost folder into the include folder of the cross compiler but that's not nice of course and I want to find out what's going on.
When cross-compiling, the toolchain file normally sets the variable CMAKE_FIND_ROOT_PATH. Combined with the CMAKE_FIND_ROOT_PATH_MODE_LIBRARY variable set to ONLY, CMAKE_FIND_ROOT_PATH variable is used as effective chroot for find_library calls, so only libraries under the given prefix(es) are searched.
Analogue variables exist to adjust the behavior for find_path (used for searching include paths) and find_program.
THe toolchain file you use actually sets CMAKE_FIND_ROOT_PATH at line 1521:
set( CMAKE_FIND_ROOT_PATH "${ANDROID_TOOLCHAIN_ROOT}/bin"
"${ANDROID_TOOLCHAIN_ROOT}/${ANDROID_TOOLCHAIN_MACHINE_NAME}"
"${ANDROID_SYSROOT}"
"${CMAKE_INSTALL_PREFIX}"
"${CMAKE_INSTALL_PREFIX}/share" )
and below sets CMAKE_FIND_ROOT_PATH_MODE_* variables to ONLY. So you need to have Boost installed under one of these directories, and give hints (like BOOST_ROOT) relative to it.
Note, that Boost should be built for the target platform (Android NDK in you case), not for the platform where you cross-compile (Linux).

Compile OpenSceneGraph with Cmake under Windows

I am trying to set up Openscenegraph 3.0.1 with Cmake. I read different blog posts but it doesn't work.
I set up the paths, click compile and selected VS11 (because I have VS 2012) and use native compiler.
Then I directly get this error:
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules CMakeCInformation.cmake:37 (get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:3 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
Looking for include file pthread.h - not found
Also, more errors with the same stack trace occur. Also also could paste them here if you wish.
Afterwards, CMake tells me "Error in configuration process, project files may be invalid"
your problem isn't in compiler version that you are using; in fact, i'm running OpenSceneGraph 3(and osgEarth) with no problems on VisualStudio 2012.
What it seems to be is a problem with Cmake/CMakeLists.txt itself. Try to build some other projects using cmake, to see whether they work, or try to use a version of CMake that is close to what OpenSceneGraph needs(look at CMAKE_MINIMUM_REQUIRED in main CMakeLists.txt file), although CMake language is meant to be compatible with earlier versions, i dont know if this is always the case.
pthread.h has nothing to do with your problem, DOESN'T EXIST in Windows(except if you are using MinGW to look for some more problems), and is not required by OSG - i think, you configured OpenThreads correctly to not use libs you don't have. Anyway, that's just part of the job CMake does on each build - looks for some random stuff, like whether it can find pthreads.h or not, that give CMake some idea about your environment and don't usually relate to the projects you build with cmake. So just ignore that line about pthread.h
Under normal circumstances, CMake shouldn't be looking for pthread for Windows. Following is the couple of lines in CMake's (2.8) FindThreads.cmake which is used for searching appropriate modules.
...
CHECK_INCLUDE_FILES("pthread.h" CMAKE_HAVE_PTHREAD_H)
if(CMAKE_HAVE_PTHREAD_H)
...
endif()
...
if(CMAKE_SYSTEM MATCHES "Windows")
set(CMAKE_USE_WIN32_THREADS_INIT 1)
set(Threads_FOUND TRUE)
endif()
As you can see, first check should fail and roll out till the second check. However, I believe that in your case, CMake somehow finds that pthread.h (maybe you have MinGW as well) This seems to be a simple conflict in your system. Check your system's PATH etc. and try to fix it.