I'm attempting to use OpenCV for Windows as supplied by opencv.org in a project I'm building with JetBrains' CLion IDE. I've installed the opencv library and configured CLion (set(OpenCV_DIR) to reference the build directory under it, but CMake issues the warning:
Found OpenCV Windows Pack but it has no binaries compatible with your configuration.
You should manually point CMake variable OpenCV_DIR to your build of OpenCV library.
I've tried some of the older distributions from opencv.org with the same results. It appears CMake is locating the OpenCV libraries, but doesn't want to use them. Why, and how do I get the OpenCV libraries to work under CLion?
The short answer is, you will probably need to build OpenCV from source in order to use it with CLion. But given the number and range of partially answered and unanswered questions here* and elsewhere on using JetBrains' CLion IDE with the OpenCV library, I think an overview is needed (my notes are from CLion 2016.3 and OpenCV 3.1, YMMV):
Though not produced by JetBrains, CMake is very central to CLion's operation. Understanding CMake therefore helps greatly in diagnosing CLion build problems. In particular CMake maintains a disk "cache" of settings which you may need to clear to incorporate changes to your environment (Tools->CMake->Reset Cache and Reload Project).
To make use of OpenCV in your build you must specify it in your project's CMakeLists.txt file. You request that CMake locate your OpenCV location and link it to your TARGET. An example of a sequence of commands from CMakeLists.txt for an executable named mushroom follows:
add_executable(mushroom ${SOURCE_FILES})
FIND_PACKAGE(OpenCV REQUIRED)
TARGET_LINK_LIBRARIES(mushroom ${OpenCV_LIBS})
(For more on FIND_PACKAGE, see CMake:How To Find Libraries.)
FIND_PACKAGE for package XXX works either by way of FindXXX.cmake files located at CMake's Modules directory, or by consulting environment variable XXXX_DIR. On my system, no FindOpenCV.cmake file was present, so I relied on the OpenCV_DIR environment variable instead. This must be set, not to the root of your OpenCV installation, but to the build folder beneath it. I used an entry in CMakeLists.txt to set this variable, e.g.:
set(OpenCV_DIR C:/Users/myacct/AppData/Local/opencv-3.0.0/build)
To link with OpenCV, CMake uses either FindOpenCV.cmake or OpenCV_DIR (see previous point above) to locate a file named OpenCVConfig.cmake. This file is generated by and ships with a particular build of OpenCV in order to document what components are present and where they are located.
Problems may occur when variable names used by OpenCVConfig.cmake conflict with those CLion has stored in its environment. In particular, if your OpenCV was built by Microsoft Visual C (MSVC), as is the Windows distribution from opencv.org, it won't work with CLion.
Because CLion's build toolchain (ControlAltS-toolchain) uses either MinGW or Cygwin, OpenCVConfig.cmake will search for OpenCV binaries under a subdirectory named mingw or cygwin and will find none because the binaries were built with MSVC (it will look in a directory like vc11 or vc12 instead). This probably means you will need to build OpenCV from source in order to use it with CLion.
Would reconfiguring OpenCVConfig.cmake to point to the MSVC binaries make this work? you may ask. Unfortunately the answer is still no, because libraries built with one compiler typically cannot be linked with another one.
OpenCVConfig.cmake or FindOpenCV.cmake likely contain diagnostic messages, but when CLion executes CMake for you, message(STATUS) calls are not displayed. To make them display, change them to message(WARNING) or message(FATAL_ERROR). But CLion 2016.3 EAP relieves this problem; see https://stackoverflow.com/a/39398373/5025060.
CLion does not indicate which .cmake script issued which diagnostics; don't assume they all come from the same script.
Hopefully this provides some general guidance on resolving CLion / CMake / OpenCV compatibility problems. Note that this does not cover compiler or linker issues; these will not appear until CMake completes its initial makefile build. Compiler or linker issues occur at a later stage and are controlled by include*(), link*() and other commands in CMakeLists.txt.
*Some related SO questions:
OpenCV Windows setup with CLion
OpenCV CLion (Cmake) linking issue - cmake reports a strange error
use OpenCV with Clion IDE on Windows
Compiling OpenCV on Windows with MinGW
Could not find module FindOpenCV.cmake ( Error in configuration process)
CMake: Of what use is find_package() if you need to specify CMAKE_MODULE_PATH anyway?
Related
I'm running Centos 7 and am trying to build hipSYCL (see here)
The issue is that hipSYCL needs to have cmake info from the LLVM build (via the LLVM_DIR cmake variable).
This is problematic for me because building LLVM requires a massive 35Gb for the libraries and exes. I don't have that much memory to spare.
I did find a build of llvm-toolset-8.0 online for Centos 7 and installed it, but to my surprise, that didn't seem to work with LLVM_DIR because there's no cmake files (since I didn't build it locally).
So, my question would be, is there a way to build hipSYCL using pre-built LLVM-clang?
If I'm missing or misunderstanding something, I'd appreciate any help.
LLVM publishes the necessary cmake files, and the binary OS packages I've seen include it, generally in a directory called /usr/lib/llvm*/lib/cmake and in a package called something like llvm-*-dev.
Edit:
Problem solved after a few steps. You can take a look at my post on the OpenCV Q&A page.
http://answers.opencv.org/question/152366/build-application-with-static-libraries/
I'm trying to statically link my C++ (CMake) application to run on another computer which does not have OpenCV installed.
So far,
I built OpenCV from source by setting BUILD_SHARED_LIBS to OFF, so I can see library files under lib directory. (with .a extension)
I edited the environment variable for the new build of OpenCV, my IDE does see include directories and files, so this step also seems ok.
Added "-static" parameter to target_link_libraries command in CMake:
target_link_libraries(HoGPeopleDetector ${OpenCV_LIBS} "-static")
Then rebuilt the application, EXE size increased to 1.6 MB from 200 KB. So I guess linking process was successful.
The application works well when I run it within my IDE. However, when I try to run it from the EXE file, it still expects DLL files. (libopencv_core310.dll and maybe more)
IDE: CLion 2017.1.2 OpenCV: 3.1
Problem solved after a few steps. You can take a look at my post on the OpenCV Q&A page.
http://answers.opencv.org/question/152366/build-application-with-static-libraries/
Overall, it was "remember to clear your CMake cache file between each invocation of cmake" and to move/copy the opencv_ffmpegXXX.dll (310 in my case), put it in the same directory with your EXE.
all!
I am trying to use OpenCV library in CLion project, but this is unsuccessful. I have opencv 3.2.0 installed with ROS kinetic at once (I can see it in /opt/ros/kinetic/include/opencv-3.2.0 directory and I can import cv2 by python). But when I use such CMakeLists.txt:
cmake_minimum_required(VERSION 3.6)
project(visual_slam)
set(CMAKE_CXX_STANDARD 11)
set(SOURCE_FILES main.cpp)
set(OpenCV_DIR /opt/ros/kinetic/include/opencv-3.2.0)
include_directories( ${OpenCV_DIR})
add_executable(visual_slam ${SOURCE_FILES})
with the next simple code:
#include <iostream>
#include <opencv2/opencv.hpp>
using namespace cv;
int main()
{
return 0;
}
I get the next error:
CMakeFiles/visual_slam.dir/main.cpp.o: In function cv::String::~String()':
/opt/ros/kinetic/include/opencv-3.2.0/opencv2/core/cvstd.hpp:664: undefined reference tocv::String::deallocate()'
CMakeFiles/visual_slam.dir/main.cpp.o: In function cv::String::operator=(cv::String const&)':
/opt/ros/kinetic/include/opencv-3.2.0/opencv2/core/cvstd.hpp:672: undefined reference tocv::String::deallocate()'
Such error was discussed also in OpenCV linking problems with ROS, but is it really so necessary to uninstall completely and then install again OpenCV? Is there any more quick solution?
Second question, how to correctly add OpenCV from ROS to CMakeLists.txt? Current CMakeLists (look above) does not look like to be flexible. I've already tried to add
find_package(OpenCV 3 REQUIRED)
target_link_libraries(visual_slam ${OpenCV_LIBRARIES} )
but the error is when CMake builds
By not providing "FindOpenCV.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OpenCV", but
CMake did not find one.
Could not find a package configuration file provided
by "OpenCV" (requested version 3) with any of the following names:
OpenCVConfig.cmake
opencv-config.cmake
The second error you are getting (namely the missing OpenCV.cmake) is actually not only related to the first one (the undefined reference to) but is the cause.
If cmake fails to find the OpenCV module the ${OpenCV_LIBS} won't do a thing meaning that target_link_libraries(visual_slam ${OpenCV_LIBRARIES} ) doesn't link against the libraries your code requires. That said I also believe that it's OpenCV_LIBS instead of OpenCV_LIBRARIES.
You can of course specify the path where the find_package(...) command looks at to find cmake modules (I think it was the CMAKE_FIND_ROOT_PATH variable) or even manually specify the root folder of your OpenCV installation and manually handle all the things that the OpenCV.cmake handles for you.
Last but not least I'm not sure if ROS Kinetic uses the latest OpenCV (what you are using namely the v3.2). You should check that and if different versions are used (very likely), you will have to build all ROS OpenCV-related packages from scratch. You might ask "Why should I do that?". Well, to avoid compatibility issues and various weird errors that may or may not occur (depending on what OpenCV functionality you use) due to version X of OpenCV being used for the binary packages of ROS and version Y present on your system (with X != Y). I had to do that with PCL (Point Cloud Library) once and it took me several days to come to this conclusion since the errors that I was getting were (typical for C++) cryptic as hell. To avoid conflicts make sure that only the one version of OpenCV is present on your system (that is can be found by cmake) that you want to use with your ROS installation. That's also the reason why the ROS binary packages are shipped through the Ubuntu repos using dependencies that are resolved by the package manager (OpenCV, PCL etc.).
PS: Since I haven't used Clion I would also suggest (before doing anything I've mentioned above) to check if it's not some hidden cmake-related setting inside the IDE that screws things up.
Does anybody know how to build cvBlobsLib using MinGW? On official page http://opencv.willowgarage.com/wiki/cvBlobsLib there is only instruction for VS.
There is also linux version of this lib http://opencv.willowgarage.com/wiki/cvBlobsLib?action=AttachFile&do=view&target=cvblobs8.3_linux.tgz , but its makefile cannot be used in windows as i see.
If you use eclipse then you dont have a lot of work:
Create a new project, using MinGW toolchain.
Go to the project properties, and under C/C++ General >> Paths and Symbols add the openCV library paths.
compile the project and it should be OK.
Use this
http://opencv.willowgarage.com/wiki/cvBlobsLib#Build_intructions
if you have more problems (especially NOTE 3)
I am using open source C++ library DCMTK from http://dicom.offis.de/dcmtk.php.en.
I have successfully compiled this library on Windows using VC++ IDE, MacOS Xcode, Mac iOS simulator.
But I am not able to compile this library on iOS device as it is ARM based architecture.
DCMTK library compiled very well on Intel architecture.
Now my problem statement is :-
I need to compile this DCMTK C++ library on ARM architecture by cross compilation.
I am using Ubuntu 64 bit machine for cross compilation.
I have installed binaries from GNU ARM tool chain from http://www.gnuarm.com/
I am using GCC toolchain 4.0 binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB] binaries for Ubuntu 64 bit machine for ARM cross compilation.
After Installing these binaries on Ubuntu I have set PATH environment variable to
PATH=$PATH/gnu_arm/bin
For configuring the DCMTK C++ library I have run the following command on shell
CC=arm-elf-gcc CXX=arm-elf-g++ AR=arm-elf-ar RANLIB=arm-elf-ranlib ARFLAGS=cruv ./configure –prefix=$home_dicom –target=arm-elf –host=arm-elf –enable-std-includes –disable-threads
It creates a make file properly. Now I am trying to compile the code by using make command, but facing so many compilation errors like :-
1) I tried to compile my first dependent C++ library that is ofstd.
I got error for DIR*, struct dirent, opendir(), closedir() calls.
It includes for these calls, but I did not found any definitions for the above calls in this header file.
2) When I compile another library oflog I got the following errors like
error: nthos was not declared in this scope
error: ntohl was not declared in this scope
error: htons was not declared in this scope
error: htonl was not declared in this scope.
These calls are networking calls and are not defined in any of the header file from GNU ARM tool.
I tried to download the sources of ARM binaries and extracted the tar files and try to copy missing header files to installed GNU ARM on Ubuntu.
For some files it compiles after doing changes to copied header files, and for some again it gives compilation errors.. There is a loop of compilation errors for every file present under DCMTK library as some of the standard header files are missing.
Please suggest if there is any other tool chain available for ARM cross compilation on Ubuntu 64 bit machine.
Or any other good solution apart from this.
Thanks!!!
Amit
There are many areas for problems when it comes to cross compiling. There are three main flags for cross compiling. -host , -target, and -build. The -host flash is the machine in which the resulting binaries will run on. The -build flash is the system in which you will be compiling on. The -target flag is for building libraries that will be used in cross compiling. So if you were to build your own gcc tool chain. So in your case you won't set the target flag as we're not building a tool chain. the -host flag will be arm-elf. And the -build flag will be amd64.
Usually a cross compilation fails if there are inconsistencies between the regular c compiler and the cross compiler. I have compiled several libraries for the avr32 with a toolchain generated by buildroot, but in some cases (socat project for example) it hasn't been possible.
Your host, your target and the CXX flags look ok. I think it is not necessary to put the AR flag (that is the idea with the host and target option).
In other hand, this is an example for the expat libraries for the avr32:
./configure --host=avr32-linux --prefix=/home/juan/builds/build_expat/ CC=avr32-linux-gcc
make; make install
I can recommend you that tries to cross compile from an ia32 architecture. I had several problems with that ubuntu in the past.