Run a c++ binary file that requires library on a different system - opencv

I have written c++ Code that requires Opencv libraries to compile in Ubuntu 12.04. When I try to run the binary generated on a different system, it asks for the library. Does this happens, or there is error in code. If no error how can I run the code than.

You should build it on the new system , if it asks for the library, you are not linking correctly.

Related

Why cv_bridge uses OpenCV 3.2 in ROS Melodic?

I have OpenCV 3.4 installed in Ubuntu 18. I also have installed ROS Melodic according to the website instructions. However, I keep on getting an error that libopencv_core.so.3.2 is required.
I already set my CMakeLists files to point to OpenCV 3.4.
However, I found out that in the file:
/ros/melodic/share/cv_bridge/cmake/cv_bridgeConfig.cmake
there is the following line hardcoded in opencv3.2:
set(libraries "cv_bridge;/usr/lib/x86_64-linux-gnu/libopencv_core.so.3.2.0;/usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.3.2.0;/usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so.3.2.0").
I tried to change it to 3.4 but I can not rebuild it.
The error I am getting is:
/opt/ros/melodic/lib/image_view/image_view: error while loading shared libraries: libopencv_core.so.3.2: cannot open shared object file: No such file or directory
Why is OpenCV 3.2 hardcoded in cv_bridge and how can I rebuild it with OpenCV 3.4?
Update:
I eventually installed OpenCV 3.2 and it worked properly.
Because opencv development speed is much faster than ROS individual module. And a lot of ROS modules went depreciated after someone left the job.
But that's by no means the end of the day( maybe end of the day for noobs). You can build it directly with any version of opencv core function(besides imshow kind of function) others should perform just fine.
The easiest way is to do is: in the console before executing catkin_make try to execute the following
export CMAKE_PREFIX_PATH=/usr/local:$CMAKE_PREFIX_PATH
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
This should give preference to your custom OpenCV installation when doing the find_package(OpenCV 3.X.0 REQUIRED). Then compile and use the function of that version.
Well if you do have to use 3.4 then I think you have to build ros version of opencv and image transport and cvbridge to the 3.4 if that's what you are targeting.
You can find the link here https://github.com/ros-gbp/opencv3-release The highest they provide seems to be 3.3

Is it possible to use TensorFlow C++ API on Windows?

I'm interested in incorporating TensorFlow into a C++ server application built in Visual Studio on Windows 10 and I need to know if that's possible.
Google recently announced Windows support for TensorFlow: https://developers.googleblog.com/2016/11/tensorflow-0-12-adds-support-for-windows.html
but from what I can tell this is just a pip install for the more commonly used Python package, and to use the C++ API you need to build the repo from source yourself: How to build and use Google TensorFlow C++ api
I tried building the project myself using bazel, but ran into issues trying to configure the build.
Is there a way to get TensorFlow C++ to work in native Windows (not using Docker or the new Windows 10 Linux subsystem, as I've seen others post about)?
Thanks,
Ian
It is certainly possible to use TensorFlow's C++ API on Windows, but it is not currently very easy. Right now, the easiest way to build against the C++ API on Windows would be to build with CMake, and adapt the CMake rules for the tf_tutorials_example_trainer project (see the source code here). Building with CMake will give you a Visual Studio project in which you can implement your C++ TensorFlow program.
Note that the tf_tutorials_example_trainer project builds a Console Application that statically links all of the TensorFlow runtime into your program. At present we have not written the necessary rules to create a reusable TensorFlow DLL, although this would be technially possible: for example, the Python extension is a DLL that includes the runtime, but does not export the necessary symbols to use TensorFlow's C or C++ APIs directly.
There is a detailed guide by Joe Antognini and a similar TensorFlow ReadMe at GitHub explaining the building of TensorFlow source via CMake. You also need to have SWIG installed on your machine which allows connecting C/C++ source with the Python scripting language. I did use Visual CMAKE (cmake-gui) with the screen capture shown below.
In the CMake configuration, I used Visual Studio 15 2017 compiler. Once this stage successfully completes, you can click on the Generate button to go ahead with the actual build process.
However, on Visual Studio 2015, when I attempted building via the "ALL_BUILD" project, the setup gave me "build tools for v141 cannot be found" error. This did not go away even when I attempted to retarget my solution. Finally, the solution got built successfully with Visual Studio 2017. You also need to manually set the SWIG_EXECUTABLE path in CMake before it successfully configures.
As indicated in the Antognini link, for me the build took about half an hour on a 16GB RAM, Core i7 machine. Once done, you might want to validate your build by attempting to run the tf_tutorials_example_trainer.exe file.
Hope this helps!
For our latest work on building TensorFlow C++ API on Windows, please look at this github page. This works on Windows 10, currently without CUDA support (only CPU).
PS:
Only the bazel build method works, because CMake is not supported and not maintained anymore, resulting in CMake configuration errors.
I had to use a downgraded version of my Visual Studio 2017 (from 15.7.5 to 15.4) by adding "VC++ 2017 version 15.4 v14.11 toolset" through the installer (Individual Components tab).
The cmake command which worked for me was:
cmake .. -A x64 -DCMAKE_BUILD_TYPE=Release ^
-T "v141,version=14.11" ^
-DSWIG_EXECUTABLE="C:/Program Files/swigwin-3.0.12/swig.exe" ^
-DPYTHON_EXECUTABLE="C:/Program Files/Python/python.exe" ^
-DPYTHON_LIBRARIES="C:/Program Files/Python/libs/python27.lib" ^
-Dtensorflow_ENABLE_GPU=ON ^
-DCUDNN_HOME="C:/Program Files/cudnn-9.2-windows10-x64-v7.1/cuda" ^
-DCUDA_TOOLKIT_ROOT_DIR="C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.0"
After the build, open tensorflow.sln in Visual Studio and build ALL_BUILD.
If you want to enable GPU computation, do check your Graphics Card here (Compute Capability > 3.5). Do remember to install all the packages (Cuda Toolkit 9.0, cuDNN, Python 3.7, SWIG, Git, CMake...) and add the paths to the environment variable in the beginning.
I made a README detailing how to I built the Tensorflow dll and .lib file for the C++ API on Windows with GPU support building from source with Bazel. Tensorflow version 1.14
The tutorial is step by step and starts at the very beginning, so you may have to scroll down past steps you have already done, like checking your hardware, installing Bazel etc.
Here is the url: https://github.com/sitting-duck/stuff/tree/master/ai/tensorflow/build_tensorflow_1.14_source_for_Windows
Probably you will want to scroll all the way down to this part:
https://github.com/sitting-duck/stuff/tree/master/ai/tensorflow/build_tensorflow_1.14_source_for_Windows#step-7-build-the-dll
It shows how to pass command to create .lib and .dll.
Then to test your .lib you should link it into your c++ project,
Then it will show you how to identify and fix the missing symbols using the TF_EXPORT macro
I am actively working on making this tutorial better so feel free to leave comments on this answer if you are having problems.

Cannot resolve symbol in libprotobuf in openwrt

I have cross compiled a client server program to be run on openwrt plattform
I have used protoc version 2.6.1 to generate the .pb.h and .pb.cc files.
I have installed he protobuf package for cross compilation using the this
I have linked the compiled protobuf libraries to the source while compiling.
But when I try to run the executable on the openwrt VM (chaos calmer) it gives me the following error.
symbol '_ZN6google8protobuf8internal13empty_string_B5cxx11E': can't
resolve the symbol in lib './opwenwrt-client'
error image
I can guess the that there is mismatch between linking library.
But I dont understand that everywhere I am using protobuf version 2.1.6.
Any kind of help would be appreciated.
This looks like it's probably caused by using a different compiler / C++ ABI to compile your application vs. libprotobuf.so. See this previous question for more:
Undefined reference to google::protobuf::internal::empty_string_[abi:cxx11]

cvBlobsLib with mingw

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)

Cross Compiling a library from intel to arm

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.

Resources