I have two versions of libusb installed:
$ pkg-config --libs libusb
-lusb
$ pkg-config --libs libusb-1.0
-lusb-1.0
For a project I want to use the libusb-1.0 version, hence I have the following in my CMakeLists.txt:
pkg_check_modules(LIBUSB REQUIRED libusb-1.0)
However, the resulting variable that I use for linking ${LIBUSB_LIBRARIES} contains only usb, not usb-1.0. So basically I'm linking against the wrong library. Why is that so? What am I doing wrong?
Related
I have an executable in cmake that depends on libssh being installed on the system.
I use this to install it:
sudo apt-get install -y libssh-dev
This is my Cmake:
cmake_minimum_required(VERSION 3.5.0)
project(validateTensor VERSION 0.0.1)
find_package(gflags QUIET)
add_executable(myapplication
"myapplication.cpp"
)
target_link_libraries(myapplication gflags teamApplication -lssh)
add_dependencies(myapplication teamApplication)
My question is how can I use cmake to check if libshh is installed on the system before adding the executable. If it is not installed then I want to exclude the executable from the build but not have the build fail.
How to check if a library (libssh) is installed with Cmake before adding executable
With find_library.
find_library(HAVE_SSH NAMES ssh)
add_executable(myapplication
myapplication.cpp
)
target_link_libraries(myapplication gflags teamApplication)
if (HAVE_SSH)
target_link_libraries(myapplication ssh)
endif()
No need to add_dependencies(myapplication teamApplication) - target_link_libraries already "does that".
I followed all the instructions for setting up gmp with cygwin,
./configure make make install and make check.
The libgmp.a is in the path C:/C++/gmp-6.1.2/.libs
I'm using this command to compile with g++
g++ -L/C:/C++/gmp-6.1.2/.libs -I/C:/C++/gmp-6.1.2 C:/foo/foo.cpp -lgmp
I get an error message that says : could not find -lgmp
What am i missing?
Why not install the gmp from the cygwin distribution?
I am trying to install the GPU support for XGBoost but I get the following error when I try to build it with CMake:
CMake Error at /usr/local/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find CUDA: Found unsuitable version "7.5", but required is at
least "8.0" (found /usr)
I only installed CUDA 8.0 and the environmental variables in .bashrc are specified as:
export PATH=/usr/local/cuda-8.0/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
How can I have CMake detect the right CUDA version?
PATH and LD_LIBRARY_PATH have no effect on cmake, so what you have tried will not work.
If you look at the documentation for find_package it is possible to provide a PATHS argument to tell cmake to look in non-standard locations
Unfortunately, if you look at the source for XGBoost's CMakeLists.txt, you can see it calls find_package(CUDA ...), but doesn't allow the user to provide a PATHS option
if(USE_CUDA)
find_package(CUDA 8.0 REQUIRED)
...
endif()
As such you are left with 2 options:
Edit XGBoost's CMakeLists.txt file, and add PATHS /usr/local/cuda-8.0 to the find_package call
Install cuda-8.0 into a standard location (eg: use /usr/local as your PREFIX, not /usr/local/cuda-8.0)
I ran into a similar issue when trying to install the R version with GPU support. The issue was that I was running the commands from their install guide:
git clone --recursive https://github.com/dmlc/xgboost
cd xgboost
git submodule init
git submodule update
cd R-package
R CMD INSTALL .
and then running the commands for GPU support:
mkdir build
cd build
cmake .. -DUSE_CUDA=ON -DR_LIB=ON
I was able to avoid the issue by running:
git clone --recursive https://github.com/dmlc/xgboost
cd xgboost
mkdir build
cd build
cmake .. -DUSE_CUDA=ON -DR_LIB=ON
make install -j
I have cmake 3.2.3 installed via pacman. I get an error when I try to use it from a msys64 shell:
$ cmake -G "MSYS Makefiles" ..
CMake Error: Could not create named generator MSYS Makefiles
cmake --help does not list it as an available generator.
I do see there is an MSYS.cmake in /usr/share/cmake-3.2.3/Modules/Platform.
What am I missing?
Instead of installing the cmake package, I think you need to install mingw-w64-i686-cmake (or the 64-bit version mingw-w64-x86_64-cmake).
I got the exact same message when trying to run cmake in the MSYS shell. Use a MinGW Shell (for instance MinGW-w64 Win64 Shell) instead.
If you compile native Windows binaries on Linux with MinGW
The MinGW and MSYS generators are only available on Windows based distributions. See #ifdef in cmake.cxx:
#if defined(_WIN32) && !defined(__CYGWIN__)
If you're cross-compiling use one of the available MinGW toolchains. See e.g. "How to use MinGW to cross compile software for Windows" chapter in CMake's wiki.
If you compile Windows binaries on Windows with MinGW
On my Windows PC I only have one CMake installation (the normal MSI Windows Installer with CMake directory added to PATH environment), which works from standard CMD shells and from my MSYS shells.
So in this case there is no need to install a special MinGW version of CMake (like e.g. for CygWin).
But I've rebuild CMake from source with MinGW-w64 several times lately to test some performance optimizations of cmake.exe and it did not work out-of-the-box. To work around the linker errors I've added -DCMAKE_EXE_LINKER_FLAGS="-Wl,--allow-multiple-definition" like recommended here and the resulting cmake.exe still supports the "MSYS Makefiles" generator.
So yes, there is - as you have commented - most probably something wrong with the pacman build.
I guess the pacman build is just broken, so I've resolved this issue by installing the Windows version of CMake from cmake.org with the msi installer.
Following the instructions to compile dlib using cmake (here) generates a static dlib library:
cd examples
mkdir build
cd build
cmake ..
cmake --build . --config Release
How can I instruct cmake to generate a shared (.so) library instead?
If you want to make a .so file then do this:
cd dclib/dlib
mkdir build
cd build
cmake -DBUILD_SHARED_LIBS=1 ..
make
sudo make install
On a unix system, that will install dlib system wide. This means installing the .so file and also the header files so you can compile programs with a command like g++ main.cpp -ldlib. Finally, on linux systems you will also need to run sudo ldconfig after installing any new shared libraries.
However, for most users, I would recommend using CMake as shown in the examples. That way would allow you to enable or disable debugging modes whenever you want and also makes distributing the project easier, both in source form and compiled form. For example, if you wanted to compile on windows then shared libraries are definitely not the way to go. Moreover, using CMake as shown in the examples will always work in a straightforward manner without any setup.
According to dlib/CMakeLists.txt, standalone (not from examples) building of dlib also creates shared library named dlib-shared:
mkdir shared_build # Build directory can be any
cd shared_build
cmake ..
cmake --build . --config Release
make install # Install library for make it acessible for others
For use this library in examples, you need to add definition of dlib library into your examples/CMakeLists.txt before include(../dlib/cmake).
examples/CMakeLists.txt:
...
PROJECT(examples)
add_library(dlib SHARED IMPORTED) # Imported(!) dlib target
set_target_properties(dlib PROPERTIES IMPORTED_LOCATION "<full path to the installed dlib-shared library file>")
# Now it is safe to include other dlib infrustucture - it won't build dlib again.
include(../dlib/cmake)
...