I have a buildroot project in which I want to add a library compiled with pascal. The reason for this is that it is a custom library and porting it to C is too much work at this point. I am compiling it for a raspberry pi CM3. How it currently works:
I have compiled the library libcustom.so on an raspberry pi (raspbian).
In buildroot I download the library from a git repository.
Now the problem I have is that the program that used this library cannot find the library (although it is in the /usr/lib/ folder). Using the ldd command I got the following output:
$ ldd /usr/lib/libcustom.so
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
ld-linux-armhf.so.3 => not found (0x00000000)
libdl.so.2 => not found (0x00000000)
libc.so.6 => not found (0x00000000)
not a dynamic executable
By checking the output given by the same command on the system where I compiled the library helped me to resolve which sub-depends were missing. Since the architecture of both the systems is the same I figured that to test what is missing I could simply copy the libraries from the compilation system to the buildroot system. (libraries that were missing were libc.so.6,libdl.so.2 and lib-linux-armhf.so.3). Now ldd gives me the following:
$ ldd /usr/lib/libcustom.so
checking sub-depends for '/lib/ld-linux-armhf.so.3'
checking sub-depends for '/usr/lib/libdl.so.2'
checking sub-depends for '/usr/lib/libc.so.6'
/lib/ld-linux-armhf.so.3 (0x76fc2000)
linux-vdso.so.1 (0x7ef00000)
checking sub-depends for '/usr/lib/libc.so.6'
/lib/ld-linux-armhf.so.3 (0x76ee8000)
linux-vdso.so.1 (0x7efeb000)
/lib/ld-linux-armhf.so.3 => /lib/ld-linux-armhf.so.3 (0x00000000)
libc.so.6 => /usr/lib/libc.so.6 (0x00000000)
/lib/ld-linux-armhf.so.3 => /lib/ld-linux-armhf.so.3 (0x00000000)
The custom library is still not working (and the ldd still points to empty (0x00000000) libraries.
I have been searching around a bit however there are still two things that I do not understand:
Why is the above solution not working? The libraries are the same architecture but as ldd points out above, some libraries still cannot be properly found.
How can I include libraries in buildroot? I have been searching for this and found how to add custom packages, but I am still clueless about how to add specific libraries (such as the one I have added by hand).
You can't take a library built on system A (Raspbian) and automagically expect this library to work on system B (built with Buildroot). Indeed the C library may be different, and the ABI may be different. Compatibility at the binary level is not trivial.
You've got two options here:
Make sure the Buildroot configuration matches the libc/ABI used on Raspbian. In your case, it seems like building a glibc toolchain in Buildroot with the EABIhf ABI should do the trick.
Build your library with Buildroot. That will require creating a package for a Pascal cross-compiler, and then a package for your library.
Is the distribution of both systems the same? Otherwise attempt to build the library cross with libraries from target.
Related
I have installed the OpenCV package in Ubuntu22.04 by sudo apt-get.
And the said OpenCV is one of the dependencies for my project.
The problem is that the target computer does not have installed OpenCV and it's impossible to use sudo permission.
How to make the OpenCV that I am using portable by the install command of Cmake? I intend to copy the OpenCV libraries when make install is invoked.
What I have tried is seen below.
Here is a portion of the CMakeLists.txt:
find_package( OpenCV REQUIRED )
message("OpenCV_LIBS:")
foreach(lib ${OpenCV_LIBS})
message("${lib}")
endforeach()
install(FILES ${OpenCV_LIBS} TYPE LIB)
Here is the output when cmake .. is invoked:
OpenCV_LIBS:
opencv_calib3d
opencv_core
opencv_dnn
opencv_features2d
opencv_flann
opencv_highgui
//omits some similar output
Here is the error message when make install is called:
CMake Error at cmake_install.cmake:130 (file):
file INSTALL cannot find "/home/john/myproject/opencv_calib3d":
No such file or directory.
And what's more, how to only make the libraries that the binary program really needs available to the customer other than sending all the libraries of OpenCV to the customer?
Tips: the customer uses the same OS.
Trying to convert a large gcc/makefile project into clang. Got it roughly working for x86, but now I'm trying to get cross compilation working.
The way it currently works is that we use Linaro's 7.1.1 arm compiler alongside its companion sysroot directory for base libraries/headers. I installed clang-6.0 and then the base clang(not sure if that mattered).
I used some commands I found to redirect clang to clang-6.0 and when I execute 'clang -v' and got
clang version 6.0.0-1ubuntu2~16.04.1 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
....
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/9
....
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.5.0
....
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.4.0
Candidate multilib: .;#m64
Selected multilib: .;#m64
It does not find the current compiler we use which is at
/usr/local/gcc-linaro-7.1.1-2017.08-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++(also a directory for *x86_64*)
I only found references to setting --sysroot, but not to a specific compiler. Definitely still lost about the relationship between clang+llvm+other compilers. I even saw somewhere saying I needed to compile llvm before I could use it?
I very roughly made changes in our make files to get the following output, basically all I had to add was '-target arm-linux-gnueabuhf' and reordered the mcpu/mfloat/marm/march so they came after -target in case it mattered
clang --sysroot=/usr/local/sysroot-glibc-linaro-2.25-2017.08-arm-linux-gnueabihf -c -std=c++0x
-g -DDEBUG_ON -target arm-linux-gnueabihf -mcpu=cortex-a7 -mfloat-abi=hard -marm -march=armv7ve
-Wall -fexceptions -fdiagnostics-show-option -Werror .... -I/usr/local/gcc-linaro-7.1.1-2017.08-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include .... and many more
I think the problem probably lies with the change I made which is the actual 'clang' call that replaced
/usr/local/gcc-linaro-7.1.1-2017.08-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ ....
End up with
fatal error: 'cstdarg' file not found
#include <cstdarg>
As said before I can already cross-compile with gcc, so I've already come across issues with std libraries that require 'build-essentials', 'g++-multilibs', etc. So they're already installed.
Looked and really haven't found anything too useful to me, I'm on linux mint 18.3 and the closest things I found were issues people had on mac and windows.
So I came across some posts mentioning setting --gcc-toolchain=/your/choice/of/cross/compiler but they also mention it not working. I discovered that if you combine this with the installation of llvm-6.0-dev(or maybe llvm-6.0-tools, tools installed dev so not 100%) it at least worked for me.
Any compiler clang or gcc needs to know where a header file is defined. The standard headers, standard libraries, c-runtime, and libc are all packaged together for each target e.g., arm64, x86 in a directory called 'sysroot'. When we compile a program we need to pass the path to sysroot for a compiler to know where to look for standard headers during compilation, and where to look for common libraries (libc, libstdc++ etc) during linkage.
Normally when we compile a program for the same machine the compiler uses the standard headers available in '/usr/include' and libraries from '/usr/lib'. When cross-compiling programs we should supply the sysroot as compiler flag. e.g. gcc --sysroot="/path/to/arm64/sysroot/usr" test.cpp. Same for clang. Most often pre-packaged cross compilers come with a script/binary that has 'sysroot' path embedded into it. e.g., aarch64-linux-gnu-gcc (https://packages.ubuntu.com/xenial/devel/gcc-aarch64-linux-gnu).
... the closest things I found were issues people had on mac and windows.
On mac the clang compiler will have the similar configuration as linux. So the details you found there should be totally applicable to yours.
More details on sysroot and cross-compilation:
https://elinux.org/images/1/15/Anatomy_of_Cross-Compilation_Toolchains.pdf
I write a code using opencv library, I used codeblocks ide configuring it to work with opencv (configuring linker settings and search directory and including all the necesary path to enviroment variable) correctly and then the program works fine. The problem is when I try to compile using minGW with g++ 6.3.0 version, it gave me the next error:
ImgSeg.cpp:2:39: fatal error: opencv2/imgproc/imgproc.hpp: No such file or
directory
#include <opencv2/imgproc/imgproc.hpp>
^
compilation terminated.
I try all possible form to put the opencv2 directory in enviroment variable but it has the same error all the time, it's a little frustrating. this is what I have on path in enviroment variable:
C:\opencv_install\lib;
C:\opencv_install\include;
C:\opencv_install\bin;
I'm using windows 7 64 and opencv 2.4.9
GCC does not search PATH when looking for include files.
You will need to tell it where to look by using the -I commandline parameter:
-IC:\opencv_install\include
When linking, you'll also need to tell GCC where to find the libraries you're linking:
-LC:\opencv_install\lib -lopencv_core
In CodeBlocks you'll need to add the former to include directories (not PATH) in the project settings.
Finally I could compile the program but I had to install mingw64 version 4.9.2 from this link. The command that I use to compile was this:
g++ -std=c++11 "name of the program.cpp" -IC:/opencv_install/include -LC:/opencv_install/lib -llibopencv_core249 -llibopencv_highgui249 -llibopencv_imgproc249 -o "name of the exe"
It's important include the -l lib that you used in the program
I am new to Ubuntu and OpenCV. Apologies for my amateurishness.
I think I messed up OpenCV installation.
I had installed OpenCV 2.4 months back. The installation was successful (built openCV from source using CMake)
Couple of days back I had also installed OpenCV 3.0 using the same procedure.
The problem began when one of my code gave a segmentation fault for seemingly no reason. On suggestion by a friend on Caffe Neural Network issues forum (https://github.com/BVLC/caffe/issues/3416), it seems that I am compiling with 3.0 headers but linking against the 2.4 libraries.
I checked /usr/local/include. It has the standard openCv header files ( I didn't understand what 'compiling with 3.0 header means' )
In /usr/local/lib I have OpenCV 3.0 libraries ( no 2.4.8 at all).
Now compilation was successful, but when I try to run it, I get the following error.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff76c49bc in cv::merge(cv::_InputArray const&,
cv::_OutputArray const&) ()
from /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4
Just to add
"pkg-config --modversion opencv"
3.0.0
whereas dpkg -l | grep libopencv
gave out
i libopencv-calib3d-dev:amd64 2.4.8+dfsg1-2ubuntu1 amd64 development files for libopencv-calib3d
ii libopencv-calib3d2.4:amd64 2.4.8+dfsg1-2ubuntu1 amd64 computer vision Camera Calibration library
ii libopencv-contrib-dev:amd64 2.4.8+dfsg1-2ubuntu1 amd64 development files for libopencv-contrib
.......
q.1> why does my code link to libopencv_core.so.2.4 instead of 3.0. I have checked in /usr/local/lib and did not see a single 2.4 library. I have tried manually defining links to header files and libraries in CMake but still same result.
q.2> Do OpenCV headers have a version number? I don't understand how they are called '2.4 headers'. I have checked the source code but did not see any specific requirement for a version of library. Then what dictates to link to 2.4 version libraries?
Sorry if this is theoretical but this would be highly beneficial to beginners like me. Please do comment for a suitable question title if the current one is not appropriate.
Thanks
Your opencv2.4 libraries are located in /usr/lib/x86_64-linux-gnu/ while the new opencv3 libraries are most likely located in /usr/local/lib. The linker is first looking in the /usr/lib/x86_64-linux-gnu/ directory, and thus finding the opencv2.4 libs first. To fix this you can tell the linker to look in /usr/local/lib first by adding the following to your ~/.bashrc file
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
Reload the bashrc file in the terminal as follows (or simply close and re-open the terminal):
source ~/.bashrc
And update the library database:
sudo ldconfig
To check the order in which the linker will search for libraries, you can use the following:
ld -lopencv_core --verbose | grep attempt
When I compile a simple program : hello_world.cpp
**I get the error-
**fatal error: cv.h: No such file or directory
compilation terminated.****
Solutions I found but didn't work:
I checked for cv.h and highgui.h if they are there, and got these results:
/home/snu/OpenCV-2.4.0/include/opencv/highgui.h
/usr/lib/perl/5.14.2/CORE/cv.h
/home/snu/OpenCV-2.4.0/include/opencv/cv.h
I checked if opencv is correctly installed by using
pkg-config opencv --libs, this is what i got :
-lopencv_calib3d -lopencv_imgproc -lopencv_contrib -lopencv_legacy -lopencv_core -lopencv_ml -lopencv_features2d -lopencv_objdetect -lopencv_flann -lopencv_video -lopencv_highgui
I made some changes in the header files of hello_world.cpp as-
#include "opencv2/highgui/highgui.hpp"
Welcome to Stack Overflow, the land of the non-answer.
"You are not doing it right, is the problem"
"Do this", with no explanation. Doesn't work.
The cmake answer is ok, but I don't really want to use cmake for the sole purpose of making a single library import.
--- end of roast, my answer:
As per https://answers.opencv.org/question/225224/opencvcvh-not-found/
OpenCV 4 discontinued the C-API in favor of the C++ one, apparently.
So you should install the latest version of OpenCV 3. This can be done using platform specific installer listed below:
https://sourceforge.net/projects/opencvlibrary/files/3.4.10/
For Linux specifically, you want this file from the ones in the link above.
Download and extract it.
Then based on these instructions to install it,
Make a directory, I called my opencv-install and put the extracted folder in it.
opencv-install/opencv-opencv-25a1900
cd opencv-install
rm opencv-opencv-25a1900/CMakeCache.txtls
cmake opencv-opencv-25a1900
make
sudo make install # global install
Then change your import to #include "opencv/cv.h"
Well how about that, you still needed cmake, but at least you don't have to make your project a "cmake project". In fact, if someone else with the same operating system has already done up to step 5, you can simply use their build !
For Linux beginners (requires Debian-base, cmake not needed)
As a little courtesy, and to put my "money" where my "mouth" is, I will provide to you my own build. Understand that using someone else's build assumes a bit more trust than compiling it yourself. I know when I first start with C/Linux compiling OS projects can be kind of daunting so.... here you go! It is for For Debian GNU/Linux 11 (bullseye) x86_64. I think this means it works on Ubuntu, and maybe other OSes that use apt. If you try it and it doesn't work, you should try a different build or make one yourself by starting at step one above.
You are probably not compiling correctly. Add the opencv-include folder in the compiler settings.
Use CMake to link libraries and include directories. It makes your life easier and also for anyone else who will be extending/reading your code in the future. You will not need to add folders specifically into projects as CMake will do that for you automatically.
For example, to link OpenCV, use the follow lines of code:
FIND_PACKAGE( OpenCV REQUIRED )
TARGET_LINK_LIBRARIES( myProject ${OpenCV_LIBS} )
please use the code below for such errors:
#include <opencv/cv.h>
in the place of
#include <cv.h>