I was able to install and build openCV following the instructions here (http://charliegerard.github.io/blog/Installing-OpenCV/). But after successfully creating the dynamic libraries I noticed in the lib directory there are 3 instances of each library named in the following format:
libopencv_LibName.3.1.0.dylib
libopencv_LibName.3.1.dylib
libopencv_LibName.dylib
Screenshot of the libraries
My next step is to single out only the header files and libraries I need for my project, and I'm not sure if I really need all 3 instances of every library in use. Why does make create all these extras? And which ones do I need?
Additional Info:
OS: OSX El Capitan
IDE: Xcode 7.3.1
When you build the opencv library it creates the actual *.dylib binary (libopencv_LibName.3.1.0.dylib) that contains the release, the major, and minor version. (Release = 3, Major = 1, Minor = 0). This allows you to have a dynamic style of linking to a specific version of the library. (For example, opencv often is not completely compatible between release versions. (From 2.x.x to 3.x.x), however it often is compatible between major/minor versions.(3.0.x to 3.1.x) )
By linking to the 3.1.0 version, you are locking in on requiring that specific version of the libary. (If you update opencv, it will still be using openCV 3.1.0).
However if you link to the 3.1 version, it is only caring about the Release and Major version, but will allow minor version updates. (Currently the 3.1 is a symlink to 3.1.0, but if you installed 3.1.1, it would now reference the 3.1.1 library.) I generally find it best to link to this one as it will allow you to update for bug fixes, but will not break any functionality.
Finally there is the version-less symlink, this one will always reference the latest version of opencv you have installed. Currently it references 3.1.0, but if you installed 3.1.1 it will now reference 3.1.1. This would not be bad, but if you were to install 4.0.0, it would now be referencing this binary and likely break some of the API.
Related
I need to install qt libraries 5.9 in Ubuntu 20.04.
sudo apt install qt5-default
will bring the latest qt release which I don't want.
I need specific qt libraries for compatibility reasons. I have applications running in the field where qt libraries are pre installed as dinamic libraries in the targets and can must be kept unchanged.
Ubuntu only offers the versions available in their repos.
If you want a specific version you can download the Qt installer (https://www.qt.io/download) and search for the version you need there. You'll find a list of builds available for download.
However, not all versions are available in their repos as well. In that case you'll have to build the version you need yourself I guess.
My Qt project use libicu for codec detection. But when building it using CMake & make, it show the following warning:
/usr/bin/ld: warning: libicui18n.so.56, needed by /opt/qt5/5.15.0/gcc_64/lib/libQt5Core.so.5.15.0, may conflict with libicui18n.so.60
The ICU used by my program is installed via apt on ubuntu 18, and the version is 60.2.
But the Qt used by my program is installed manually by the online installer, and the version of ICU is 58.x.
The reason why I don't installed qt via apt is that the project uses the features introduced in Qt5.15, and currently the highest version of Qt from apt is 5.12(on ubuntu 20.04).
When I scanning libraries, I find libicui18n in the qt root.
So I wonder if I can directly use it.
Or is there any way to solve this conflict?
Of course, rebuilding qt or building it on Arch Linux are possible solutions.
But this is quite complex, especially my program will be built on three platforms.
I have build servers that run Ubuntu 18.04 (in a Docker container), but I need to build binaries (various static and shared libraries and executables) for older versions of Ubuntu (e.g. 16.04), without having to install an older version of the OS.
Currently we use sysroot toolchains (that include compiler and libraries etc) and CMake toolchain files for building for other targets (e.g. ARM Poky/Yocto), and it would be ideal if we could use the same approach for building for older (or potentially newer) versions of Ubuntu.
Is it possible?
Anything is possible, but the easiest thing you can do is create a new Docker image (or some other type of machine) with an older OS on it. Then everything will "just work."
If you really don't want to do that, you need to identify all the dependencies, starting with libc, which have symbols missing on the older platform, then figure out how to avoid using those symbols. This will probably waste a ton of time, especially considering you already have one build container (making a second one shouldn't be hard).
I just downloaded biicode and tried to follow the getting started instructions but received an error about the Cmake 3.0 or higher being required.
However, ubuntu 14.4 uses "cmake version 2.8.12.2"
Is there a way to use biicode with 2.8 or am I stuck installing the newer version of CMake?
TIA!
No, biicode requires cmake > 3.0. There is a setup command that helps installing it:
$ bii setup:cpp
This will install CMake >3.0 in /home/user/biicode_env, and add it to the path, so it doesnt interfere/overwrite your current 2.8 installation. Biicode needs that executing "cmake" in the console actually uses 3.0, so it should be first in the path. You can manage it very easily in two different ways, with a symbolic link (/usr/bin) that you redirect as needed or adding/removing an entry in the path before executing biicode.
This is a different thing, but I woiuld like to say that I have migrated existing projects from cmake 2.8 to 3.0 without any problems, and 3.0 runs great and has useful new features. So I would recommend regular cmake users to upgrade if possible.
No, there isn't any way to change this requirement because internal biicode CMake has features, like the use of INTERFACE libraries, which are only available on CMake 3.0 or later. However, don't worry about upgrading CMake version, this one always keeps a exhaustive compatibility with older versions ;)
I regularly use Code::Blocks and MinGW for my C/C++ projects. I would like to be able to use OpenCV, since it has a nice library for computer vision projects. They have dropped support for MinGW. I have heard you can build it on your own somehow, but I have no experience doing this with 3rd party libraries. Can someone explain how to build it in a simple way for MinGW?
There is, or at least there was at least until 2.4.6, precompiled version of opencv that works out of the box with mingw as long as you use the dw2(standard) version of mingw.
since i needed sjlj support i had to build my own version of openCV 2.4.6
I did he following - i am pretty sure it will work for the current openCV version as well
Setup your preferred Mingw Environment - i would strongly recommend to use gcc 4.5 or newer
Intstall Msys
Intall Cmake - you can get a binary package
Start the Cmake GUI
Select the openCV source folder
Click Configure and select MSYS-Makfiles
Errors in the first run of Configure might be resolved if you run Configure again
Click Generate
use MSYS make to run the generated makefile
Copy all desired libraries and include files to your mingw-installation or your project