OpenCV CMake package version error

Problem

I was compiling OpenCV using CMake and it threw up this error:

CMake Warning at cmake/OpenCVPackaging.cmake:23 (message):
  CPACK_PACKAGE_VERSION does not match version provided by version.hpp
  header!
Call Stack (most recent call first):
  CMakeLists.txt:1105 (include)

Solution

Open cmake/OpenCVPackaging.cmake file and add the version of OpenCV using a line set(OPENCV_VCSVERSION "2.4.13"). Place the line anywhere above the first use of OPENCV_VCSVERSION.

Advertisements

OpenCV CUDA CMake error

Problem

I was building OpenCV using CMake and got this error:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
opencv_dep_CUDA_nppi_LIBRARY

Solution

The error was related to CUDA and probably some dependency on the NVIDIA Performance Primitives (NPP) library. Since, I needed neither, I rebuilt OpenCV without CUDA support as described here by setting WITH_CUDA=OFF.

NVCC argument redefinition error

Problem

I was trying to build a CUDA project that worked on one computer on a second computer. Though this project built without problems on the first computer, nvcc gave an argument redefinition error on the second computer:

nvcc fatal   : redefinition of argument 'std'

Solution

At first, I thought that the compilation error was arising from the source code. Actually, the error is being reported about a compilation argument to nvcc. It is saying that a std argument has been provided more than once.

This project was using CMake, so the actual compilation commands invoked by make are hidden. I used the VERBOSE trick, described here, to view the actual commands issued to the C++ and CUDA compilers. Not surprisingly, I found that the -std=c++11 argument was being passed twice. But why?

I checked the CMakeLists.txt file and found that indeed the C++11 argument was being passed to the compiler twice by setting it in both CMAKE_CXX_FLAGS and CUDA_NVCC_FLAGS. How and why was this working fine on the first computer? Turns out that the older CMake used on the first computer would not pass the C++ flag to NVCC, so it had to be specifically redefined for CUDA compiler flags.

The second computer was using a newer version of Ubuntu, with newer version of CMake. This was intelligent enough to pass a C++ flag to the CUDA NVCC compiler too. But since the NVCC flag of the same name also existed, it was causing the argument redefinition error. Removing the flag from the CUDA flags made the problem go away.

How to view CMake cache variables

Running CMake for a project creates many variables that are required for its own operation and for the project being built. If you use the CMake GUI, then these are the variables which you see populated after you perform Configure and then Generate. When you want to diagnose a CMake build problem at the shell, it is useful to be able to view these variables.

  • To perform a CMake build and then print the cache variables:
$ cmake -L ..

Note that in the above command, I am in the build directory and the CMakeLists.txt is in the parent directory. This command builds as usual and at the end prints the CMake variables and their values.

  • To perform a CMake build and list all the cache variables, including advanced variables:
$ cmake -LA ..

Note that the number of variables that are printed can be quite high for big projects. I have seen it run into the hundreds.

  • To perform a CMake build and list all the cache variables and print the help documentation about each variable too:
$ cmake -LAH ..
  • If you have already done a CMake build and just need to print out the cache variables, add the -N option:
$ cmake -L -N

This command assumes that the current directory is the build directory containing the cache files, so no directory needs to be specified. This command is quick because it does not do a CMake build. Additionally, you can also add the -AH options as before if you want.

Tried with: CMake 2.8.12.2 and Ubuntu 16.04

CMake error building with Python libraries

Problem

I got this error from CMake when building a project that needs to link with Python 3.4 libraries:

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.3", minimum required is "3.0")
-- Could NOT find PythonLibs (missing:  PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) (Required is at least version "3.0")

Solution

Turns out that the CMake available on my system only supported finding Python 3 packages upto version 3.3. To change it to support Python 3.4 was possible by editing two files:

  • In file /usr/share/cmake-3.4/Modules/FindPythonInterp.cmake find the line containing _PYTHON3_VERSIONS and prepend 3.4 to the versions already listed there.

  • In file /usr/share/cmake-3.4/Modules/FindPythonLibs.cmake find the line containing _PYTHON3_VERSIONS and prepend 3.4 to the versions already listed there.

I was able to build with Python 3.x libraries after that.

How to import CMake project in Qt Creator

Importing a CMake project into Qt Creator is easier than it is with Eclipse (which is described here). The problem is that you cannot do this properly by using the Import option. Counter-intuitively, you need to Open Project to import a CMake project and make a Qt Creator project from it. After this operation, the project will be available in Qt Creator always, with auto-complete (thanks to indexing) and building (thanks to make).

To do this:

  • Do Open file or project and open the CMakeLists.txt file.
  • Choose the Build directory properly. Qt Creator will create a .cbp file here with the name of the CMake project.
  • Qt Creator will ask you to run cmake once, so that it can learn the include, library and build directories.
  • You are now in the project Qt Creator has created for you. It will index the files perfectly, so you get excellent auto-complete (better than Eclipse).
  • Click the Projects button in left column and you will be able to set the command options to build and the environment variables for build.

Tried with: Qt Creator 3.5.0 and Ubuntu 14.04

CMake error on Qt5Core

Problem

I tried to build source code that uses Qt5 using CMake. It quit with this error:

CMake Error at CMakeLists.txt:20 (find_package):
  By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5Core", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5Core" with any
  of the following names:

    Qt5CoreConfig.cmake
    qt5core-config.cmake

  Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set
  "Qt5Core_DIR" to a directory containing one of the above files.  If
  "Qt5Core" provides a separate development package or SDK, be sure it has
  been installed.

Solution

I checked for Qt5 packages and they seemed to be installed. There has been a naming change between Qt4 and Qt5 packages in Ubuntu and that threw me off.

What was needed is the package qtbase5-dev. Once I installed it, this error was solved:

$ sudo apt install qtbase5-dev

Tried with: Ubuntu 14.04

How to build and use GLFW

GLFW is a library for OpenGL created by Camilla Berglund. It is a modern replacement to GLUT, to draw windows and handle input.

GLFW 2.x

Ubuntu ships with an ancient version of GLFW that can be installed easily:

$ sudo apt install libglfw-dev

However, it is highly recommended to use GLFW 3.x. It has a different API and your source code and build options will need to be changed to use it.

To remove this ancient GLFW:

$ sudo apt remove libglfw-dev glfw2

GLFW 3.x

I like to install GLFW from Github. You could also get one of its stable releases, the installation steps would be the same for either.

  • Get the source:
$ git clone https://github.com/glfw/glfw.git
  • Build the library. Note that we request CMake to create shared library files. Why this is not the default on Linux puzzles me!
$ cd glfw
$ mkdir build
$ cd build
$ cmake -D BUILD_SHARED_LIBS=ON ..
  • Install the library:
$ sudo make install

Note that I highly recommend using checkinstall as described here instead of doing this.

  • Update the dynamic linker cache, so that the libglfw.so shared library file can be loaded at runtime:
$ sudo ldconfig

If you do not do this, you get an error similar to that described here.

  • To use GLFW 3.x calls in your code, include the header file:
#include <GLFW/glfw3.h>
  • To link and build your code use the library directive: -lglfw to your build options or CMake.

Tried with: GLFW 20150825 and Ubuntu 14.04

How to set link directories in CMake

For most common libraries, CMake has inbuilt modules which find and include them for compilation and linking. But, there are situations where you need to use library files (say *.so) that are in a custom directory somewhere that need to be linked with the code you are building.

One or more of such paths which should be requested to search for library files while linking can be specified like this:

link_directories(
    /home/joe/bellringer/lib64
    /home/joe/globespin/libs
)

The library files in these directories can now be specified in link_libraries or target_link_libraries using the usual -l syntax.

Reference: link_directories

Tried with: CMake 2.8.12.2 and Ubuntu 14.04

How to use shell environment variables in CMake

Many developer SDKs and libraries set their own environment variables. For example, installing OpenNI2 sets OPENNI2_INCLUDE to the path containing its header files. It would be convenient to use these shell environment variables directly in CMake without having to create another CMake variable for it.

This can be done in CMake easily. For example to set the above environment variable as an include directory:

include_directories(
    /home/joe/globespin/include
    $ENV{OPENNI2_INCLUDE}
)

Tried with: CMake 2.8.12.2 and Ubuntu 14.04