I'm using tensorflow 1.4 & qt in ubuntu 16.04. The problem is when I include tensorflow(version: 1.4) and opencv (version: 3.2.0) simultaneously, protobuf is conflicted. The error msg is as follows:
[libprotobuf FATAL external/protobuf_archive/src/google/protobuf/stubs/common.cc:79] This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.4.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/build/mir-O8_xaj/mir-0.26.3+16.04.20170605/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc".)
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.4.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/build/mir-O8_xaj/mir-0.26.3+16.04.20170605/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc".)
I learnt from some place that opencv with gtk-3.x will use protobuf 2.6.1 which caused the above problem, and installing opencv with gtk-2.x will not depend on protobuf. And part of the opencv cmake msg is as follows, cmake use gtk 3.x automaticly.
GUI:
-- QT: NO
-- GTK+ 3.x: YES (ver 3.18.9)
-- GThread : YES (ver 2.48.2)
-- GtkGlExt: NO
-- OpenGL support: NO
-- VTK support: NO
And the system gtk information is as follows:
$ pkg-config --modversion gtk+-2.0
$ 2.24.30
Here is the problem.How I can install opencv with gtk 2.x using cmake?
For me you just need to install the required dependency, which is a version of protobuf compatible with 2.6.1.
A quick search on packages.ubuntu.com shows that the package libprotobuf9v5 provides protocol buffers C++ library and is in version 2.6.1. Just try to install this.
BTW, going back in the past using outdated technologies like GTK+2 is a bad move. If you really want to change your toolkit, selecting it is just a matter of defining the right options on the cmake call. In the toplevel CMakeLists.txt one can easily find WITH_GTK, WITH_GTK2, and WITH_QT options. Enable them on the command line call to cmake, or using cmake-gui And if you're already using Qt yourself, just rebuild using the Qt backend instead of an old GTK one.
Related
I'm trying to build opencv-4.5.1 with tesseract-5.0.0 using cmake under Windows 10. First, I built tesseract with C++17 (by default) as static lib. Then, when configuring opencv, cmake issues the message:
Tesseract: YES (ver 5.0.0-alpha-20201231)
Can't use Tesseract (details: https://github.com/opencv/opencv_contrib/pull/2220)
Looking closely at the opencv flags I found that it was configured with C++11. Then I rebuilt tesseract with C++11 support, but this error persists. As a result, opencv is built, but when creating an OCRTesseract object, a message is displayed that tesseract was not found.
Then I tried the older tesseract-4.1.0 version. It is labeled LSTM. The error persisted.
What moment did I miss?
I work with the Net-SNMP library with C++ on an Debian inside a beaglebone back. I used to work with net-snmp 5.7.1 version. However, I need to upgrade it to 5.9. I did the steps of this tutorial: http://www.cloud-rocket.com/2013/08/compiling-and-installing-net-snmp-for-beaglebone/, but I changed the configuration step to just:
./configure --prefix=/usr --build=i686-linux --host=arm --target=arm-linux --with-ar=/home/ubuntu/angstrom-toolchain/arm/bin/arm-angstrom-linux-gnueabi-ar --with-cc=/home/ubuntu/angstrom-toolchain/arm/bin/arm-angstrom-linux-gnueabi-gcc --with-linkcc=/home/ubuntu/angstrom-toolchain/arm/bin/arm-angstrom-linux-gnueabi-gcc
I updated the compiled files in the beagleboneblack, then I could see the version 5.9 when I executed the command:
$snmpd -version
I also updated the Libraries in the path of the G++ Linker, compiled and uploaded the C++ firmware to beaglebone.
However, inside the C++ firmware, when I call the funcion:
init_snmp("agent");
The output is:
NET-SNMP version 5.7.1 AgentX subagent connected
I was expecting the 5.9 version of it. What I'm doing wrong?
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.
When I copy my executable and lib dependencies to another computer and run the program I get this error:
This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.5.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library.
This error only happens in the new computer. I can run my program on my computer without any issue.
I tried to check with ldd -d and objdump -p engine | grep NEEDED which of the libs are that have protobuf in them, but I can't find them.
My program uses: opencv with Cuda, boost, tensorflow, tensorRT.
Both of the computer OS is Ubuntu 16.04.6 LTS.
How can I find which part has the issue with this conflict?
I tried to recompile opencv without protobuf by adding -DBUILD_PROTOBUF=OFF -DPROTOBUF_UPDATE_FILES=ON -DPROTOBUF_INCLUDE_DIR=/usr/include -DPROTOBUF_LIBRARY=/usr/lib/x86_64-linux-gnu/libprotobuf.so.
This did not solve the issue.
You have two different version libprotobuf, with one installed in /usr/local/lib/ by dynamic library.
But when you build your program, you include other version of libprotobuf.
You can reinstall libprotobuf to solve this question.
If you install libprotobuf from source, make sure you added the flag -Dprotobuf_BUILD_SHARED_LIBS=ON.
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.