I wrote a small project using C++, OpenCV 2.2 and g++ in Ubuntu 11.04. I need to make a library (.so would be better), but I want it to run on the other computer, without OpenCV installed.
I've tried to build dynamic library using -shared and -fPIC flags for g++, and copied OpenCV .so libs to the working directory. Actually I need only core and feature2d, but actually it requested lot's of other libs, including highgui, which also has many dependencies.
I tried static linking, using -Wl,-Bstatic flags, but also unsuccessfully.
Did someone has the same problems? I would appreciate any kind of help.
It is possible to build OpenCV without dependencies from system libraries. To turn of all the dependencies for OpenCV 2.2 on Linux you can run cmake with following arguments:
cmake -DWITH_1394=OFF -DWITH_CUDA=OFF -DWITH_EIGEN2=OFF -DWITH_FFMPEG=OFF -DWITH_GSTREAMER=OFF -DWITH_GTK=OFF -DWITH_OPENEXR=OFF -DWITH_PVAPI=OFF -DWITH_QT=OFF -DWITH_TBB=OFF -DWITH_UNICAP=OFF -DWITH_V4L=OFF -DWITH_XINE=OFF -DUSE_IPP=OFF -DOPENCV_BUILD_3RDPARTY_LIBS=ON ..
But in this case you will not be able to use many of functions form highgui module:
video reading and writing
working with camera
all functions working with GUI (like imshow)
Related
I am writing a little project in which I want to call a function from a shared library. For that I want to use libdl.so's dlopen() function.
I have everything set up so that it will work just fine when I build and run it as a 64bit application. However as soon as I am compiling it as a 32bit application and then try to run it, it won't be able to load any library.
dlopen() simply returns null and a call to dlerror() reveals
libtbbmalloc.so.2: cannot open shared object file: No such file or directory
Now I am guessing that I have to somehow install a 32bit version of that library but I can't find it in the package manager and what I have found online isn't too helpful either.
Does someone know that the problem is and/or how I could fic it?
I am building my project via cmake v3.10 and in the CMakeLists.txt I am using this instructions for 32bit:
set_target_properties(clib PROPERTIES COMPILE_FLAGS "-m32" LINK_FLAGS "-m32")
target_link_libraries(clib /usr/lib32/libdl.so)
I have installed the package g++-multilib and my g++ version is 7.3.0.
I am attempting to build my program on Linux Mint 18.3 (6bit).
With the help of #Lorinczy Zsigmond in the comments, I was able to find the problem: I had to install the packages libtbb-dev:i836 and libz-dev:i836 in order for the function loading to work properly.
I'm trying to build wxWidgets library into a custom path on a Fedora 27 operative system.
I achieved the wx-config file path recognition and works with the cmake execution. Also, I load libraries and include dirs based on modified wxWidgets finder cmake file that sets thewx-config custom path successfully.
But cmake does not load my wxWidgets configuration. I mean, wx_gtk2u_jpeg-3.1 builded lib could not be founded (suposed to be /usr/lib/libwx_gtk2u_jpeg-3.1.so). I need jpeg dependency from wxWidgets for my project.
I'm sure that problem is not about cmake files. However, the problem is wxWidgets compilation because cmake can found the other builded dependencies into /usr/lib/
I actually installed the libjpeg-turbo-devel package that includes the libjpeg.h needed for wxWidgets building without success of libwx_gtk2u_jpeg-3.1.so creation.
The weirdest part is that $ wx-config --libs shows the wx_gtk2u_jpeg-3.1 lib to be linked and the hint paths that it should be founded.
wxWidgets commands for building:
$ ./configure --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin --with-zlib=builtin --with-expat=builtin --enable-webviewwebkit=no --prefix=/opt/cpp_dependencies/2018Q1/usr'
$ make -j 4
$ make install
You can check out my cmake files, the cmake output and wxWidgets building output in order to reproducing it: https://gist.github.com/jjalvarezl/b70accae269ef56c56010bedf157c27f
You can see line 1543 of wxWidgets building output file that jpeg library is buildin, and, 1564 of same file, the make install command that installs all libwx_<lib_name>.so libraries into final /usr/lib path. Anyway, no one contains the needed library.
Please show the exact error message, as it's not clear what the actual problem is. What I can say, is that the different built-in versions of 3rd party libraries, such as libjpeg, are always static libraries, even when wxWidgets themselves are shared. I.e. you're never going to have libwx_gtk2u_jpeg-3.1.so, only .a.
I'd also strongly recommend using system versions of the 3rd party libraries under Unix systems. This means that your wxWidgets applications will get security updates from your OS vendor and you don't risk running into any incompatibilities due to using 2 different versions of the same library in your application.
My system is Windows 64bit, and I am using VS 2013. I am using the latest OpenCV 2.4 build for Windows.
I am trying to compile a simple C program which uses OpenCV 2.4. The dynamic link version works well. But I need a static linked one so I think I can just copy this one executable to my working environment.
When I try to run my statically linked executable, the program cannot read my video file, but does not throw exceptions of any kind either. But if I put opencv dlls into my program's directory, the programm will work.
I have set the additional libraries path to include opencv\build\x64\vc12\staticlib. I have set the Runtime Library to Multi-threaded, but I think I still missed some option. I just could not figure it out.
Here's the question I posted on OpenCV's forum. To summarise:
Build your own static library from scratch.
Update
Re-post the steps from the post:
Build static ffmpeg
Build static opencv and static link to ffmpeg
Build the program and static link to the opencv & ffmpeg libraries
Caveats: You may face legal issues if you statically link to the ffmpeg libraries.
Now I have a opencv project which was build in Linux platform, and of course it can run successfully.
I want to share the execution file of the project to other person(like boss), and other person's computer didn't install opencv
Is it possible to modified the makefile file to let the other person's computer run the project without installing opencv library?
You have to link to static OpenCV libraries. This way they are bundled with your executable, so the target system doesn't have to have shared libraries installed.
I've successfully built my executable with RPATH=$ORIGIN, which mean that I can put the openCV libraries in the same directory as the executable. This means they don't clash with existing openCV installations (or lack thereof)
When you run the executable, you will need the libraries to process the image. So, those libraries must be present for the processing purpose either by providing them in your system or by linking them to your executable itself.
I'm trying to get started with a domain-specific language (C++ extension) for image processing called Halide.
Following the Halide README, here's what I've tried:
Downloaded the Ubuntu 12.04 Halide binary, and extracted in a directory called ~/halide.
In the ~/halide directory, I created hello_halide.cpp, as described in the Using Halide section of this page.
Tried to compile hello_halide.cpp:
g++-4.6 -std=c++0x hello_halide.cpp -L halide -lHalide -ldl -lpthread -o hello_halide
But, g++ can't find libhalide:
/usr/bin/ld: error: cannot find -lHalide
Tried adding ~/halide to my $PATH and $LD_LIBRARY_PATH, but this didn't help.
How can I compile this basic hello_halide.cpp Halide program?
Notes:
CUDA is one of Halide's dependencies. I have CUDA installed, and I can compile/run CUDA programs.
I'm using Ubuntu 12.04.
My g++ version is 4.6.3.
-L halide tells the linker to look for the library in the subdirectory halide. In this case that means that your source file hello_halide.cpp should be in a folder ~/myfolder/, and the library libHalide.so at ~/myfolder/halide/libHalide.so (or .a if it's static). If it's somewhere else, pass an absolute path to -L.
Your idea of setting LD_LIBRARY_PATH or PATH does not work since the latter is for directories that will be searched for executables and the former is for directories that will be searched for shared libraries when you launch an executable that needs shared libraries.