In my C++ project, I'm compiling and linking against a library that makes use of OpenSSL.
I need to compile this project for my BeagleBone which has openssl installed by default. I have downloaded libssl-dev on my development machine.
Thus, I can compile the project fine if I'm compiling for my development machine on x86_64, but I am not able to successfully cross compile:
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lssl
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lcrypto
This indicates I need to have armhf binaries for OpenSSL, which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it.
Is the only way around this cross-compiling OpenSSL myself? Where would I then need to install the .so files (I guess make install would be a bad idea?)
This indicates I need to have armhf binaries for OpenSSL
Correct.
which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it.
You appear to think that shared libraries are only needed at runtime, but that is not the case.
ELF stands for executable and linking format. The .so is very much needed at static link time to construct various tables in the main executable, which will then be used by the loader at runtime to resolve references from the main executable to the .so.
If you are familiar with Win32, you can think of .so as a combination of Win32 .LIB and .DLL packed into a single file.
Related
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.
Is it possible to compile tesseract into one binary?
I use the following to compile a program, but how is it possible to compile tesseract shared libraries into one binary so the program is 100% portable and you dont need tesseract to be installed on the current system?
Its not necessary to compile leptonica into the binary
g++ -std=c++11 txtocr.cpp -o txtocr -llept -ltesseract
For that you need to use a Static Library, on unix systems they usually ends with the .a extension, and a Shared Library ends with .so
If you only have the .so (or .dylib on mac, .dll on windows) library of the tesseract, then you cannot compile it as a single binary.
Use the -static argument to g++ to compile a static binary.
Try pyInstaller, it support Windows, Linux and OSX. Below sample command is to create an one file bundle executable.
pyinstaller -F /path/to/myscript.py
It can be installed by pip install pyinstaller, or use MacPorts or Homebrew to install in OSX.
This link below
https://github.com/tesseract-ocr/tesseract)
will help you more. Whether you are going to compile from scratch or uselibraries which are already compiled for you for the desired OS.
There are similar topics, but I haven't managed to find my answer in them.
I am building a test console application using the code::blocks IDE. It needs to load a DVB shared library called libhdhomerun.so (from Silicon Dust) for the HD Homerun DVB tuners. The HDHR tuner library has being installed using ./configure, ..., sudo make install, ldconfig etc and it all works with their utilities (built at the same time). So - the library is there and OK.
The library installed itself into /usr/local/lib. There is actually no symlink to it as there is with other shared libraries, but then it doesn't have any version information on the end either.
When I build the code (having explicitly included /usr/local/lib/libhdhomerun.so), the ld stage fails with
"cannot find -lhdhomerun.so"
I have tried every combination of including (/usr/local/lib/) libhdhomerun.so, hdhomerun.so, libhdhomerun, hdhomerun, creating a symlink to it etc. Nothing makes any difference.
The bizarre thing is that I have udev, mysql and libdvbv5 shared libraries included in exactly the same way, and they are fine. The only one that will not link is hdhomerun.
If I run a manual verbose link step from the command line "ld -lhdhomerun.so --verbose", it does fail - because it is trying to find libhdhomerun.so.so.
Any suggestions gratefully received - but I do need to keep using code::blocks.
To link the library properly, you need to have library path defined in your environment, and use proper library name with -l flag. Library path is defined in LD_LIBRARY_PATH environment variable. For -l flag to g++, library extension should not be provided - as you already observed, so in your case it should be like this:
-lhdhomerun
I am trying to install Poco on Mac. I downloaded the basic edition from here. As per the instructions, I did configure, then did make. It took a long time, but it succeeded (my make version is 3.81).
After this, when I did sudo make install, it finished pretty quickly. But as per the documentation, which states that I should have the libraries installed in /usr/local, I don't see them. The /user/local/include/Poco has all necessary header files, and /user/local/lib has lot of dynamic libraries like libPocoFoundationd.30.dylib, etc, but I don't see the libraries which I need to use.
How do I get them? My system is OS X 10.10, Yosemite.
If you have the entries like libPoco*.30.dylib (dynamic library binary) and libPoco*.dylib (link to the library), that's it. If you are looking for the static libraries, they are not built by default. To build static libraries, do
configure --static
and, after make install, in /usr/local/lib you will find libPoco*.a etc.
I am working on a vision project using a beaglebone white. I am using an i686 machine running Ubuntu 12.04 LTS and the eclipse IDE with CDT plugin as my development machine. My beaglebone is running the latest Angstrom distro provided from beaglebone.org. My question has to do with general cross-compiling methodologies.
My program uses OpenCV and Curl c++ libraries.
So far on my host machine I have downloaded the latest OpenCV and Curl libraries and have crossed compiled them for the arm-linux architecture.
My test program compiles without errors on my development pc and generates an executable.
I use SCP to transfer the executable to the beaglebone over ethernet, and when I run my program I get the following error on the beaglebone:
"error while loading shared libraries: libopencv_core.so.3.0: cannot open shared object file: No such file or directory"
On the host computer OpenCV and Curl source and libraries are in two separate locations.
For OpenCV I used:
sudo cmake -DSOFTFP=ON -DCMAKE_TOOLCHAIN_FILE=../arm-gnueabi.toolchain.cmake ../../..
sudo make
sudo make install
which creates arm-compiled version of OpenCV in the /home/OpenCVArm/opencv/platforms/linux/build_hardfp/install/ on my host.
For Curl I used:
sudo ./configure --host=arm-linux-gnueabi --build=i686-linux CFLAGS='-Os' --with-ssl=/usr/bin/openssl --enable-smtp
sudo make
sudo make install
which creates the Arm compiled curl library is in /usr/local/ on the host.
to link all the libraries in my program I use the following script in Eclipse:
arm-linux-gnueabi-g++ -L/usr/local/lib -L/home/OpenCVArm/opencv/platforms/linux/build_hardfp/install/lib -L/usr/arm-linux-gnueabi/lib -o "HelloWorlTest" ./src/HelloWorlTest.o -lopencv_highgui -lopencv_core -lopencv_imgproc -lcurl
My questions are:
It appears I can get rid of my shared library error on the bone, by copying the appropriate libraries from my arm-compiled versions on the host to the target. So the target needs a copy of all libraries as well in order for the program to run. Since these are shared libraries and they are not included in the final executable, why do I need to compile the source for the target platform on the host in order to make the host linker happy? It appears the arm-compiled versions of the shared libraries are never used on the host. I initially thought it was so they would be packaged with the executable, but that is obviously incorrect.
If I copy the needed shared libraries from the host to the directory where the executable is stored on the target, the program still fails to find the shared libraries. The program will only run if I place a copy of the needed .so files in the /usr/lib/ folder on the target. What folders are searched for shared libraries when running an executable? Why won't it find shared libraries within its own local folder?
As I add more libraries to my project, what is the best way to manage them, and get them on the target. I really do not want to download the source on my host, cross-compile for arm, and then sift through all the libraries generated to only transfer the .so files I need on the bone. What is the proper way to provided the target with only the needed libraries for the executable? Is there a tool/plugin to manage or make this process automated?
How can I determine what are the required libraries irrespective of all the libraries I added to the eclipse linker?
If I wanted to tell eclipse to not use shared libraries how do I change the compile scripts for OpenCV, Curl, and modify eclipse so that static libraries are used instead?
When doing embedded programming, and cross-compiling is it more typical to use shared libraries or static libraries?
Thanks for the help.
You are just making the linker happy having the shared library on the host. It looks in the shared libraries to make sure the symbols your program uses are resolved. They are not linked in or used for anything else.
/lib and /usr/lib are the usual place to find shared libraries. You can add directories to the dynamic loader's search path by defining the LD_LIBRARY_PATH environment variable:
setenv LD_LIBRARY_PATH /home/me/lib:/home/me/lib2
I have no clue if there is some kind of tool/plugin for this. I use scp. ;-)
The ldd command will tell you what shared libraries an executable uses.
Good question. I've never built them. Often packages will build both shared and static libraries.
I don't know if is more typical to use shared libraries or not. I generally use static libraries. In my ELLCC cross compiler project.
I have used ELLCC to build itself. The resulting statically linked executables were actually smaller than the gcc compiled executable that uses shared libraries. Of course that is with an entirely different set of C++ and C standard libraries.