在交叉编译后，无法在目标上找到共享库，Ubuntu到Beaglebone

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.

我正在使用beaglebone white制作视觉项目。我正在使用运行Ubuntu 12.04 LTS的i686机器和带CDT插件的eclipse IDE作为我的开发机器。我的beaglebone正在运行beaglebone.org提供的最新Angstrom发行版。我的问题与一般的交叉编译方法有关。

My program uses OpenCV and Curl c++ libraries.

我的程序使用OpenCV和Curl c ++库。

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.

到目前为止,在我的主机上,我已经下载了最新的OpenCV和Curl库,并且已经为arm-linux架构编译了它们。

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:

我使用SCP通过以太网将可执行文件传输到beaglebone,当我运行我的程序时,我在beaglebone上收到以下错误:

"error while loading shared libraries: libopencv_core.so.3.0: cannot open shared object file: No such file or directory"

“加载共享库时出错:libopencv_core.so.3.0:无法打开共享对象文件:没有这样的文件或目录”

On the host computer OpenCV and Curl source and libraries are in two separate locations.

在主机上,OpenCV和Curl源和库位于两个不同的位置。

For OpenCV I used:

对于我使用的OpenCV:

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.

它在我的主机上的/ home / OpenCVArm / opencv / platforms / linux / build_hardfp / install /中创建了ARM编译版本的OpenCV。

For Curl I used:

对于Curl我用过:

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.

创建Arm编译的curl库位于主机上的/ usr / local /中。

to link all the libraries in my program I use the following script in Eclipse:

要链接我程序中的所有库,我在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.

看来我可以通过将主机上的arm编译版本中的相应库复制到目标来消除骨骼上的共享库错误。因此目标需要所有库的副本以便程序运行。由于这些是共享库并且它们未包含在最终可执行文件中,为什么我需要在主机上编译目标平台的源代码以使主机链接器满意?看起来共享库的arm编译版本从未在主机上使用过。我最初认为它是这样的,他们将与可执行文件打包,但这显然是不正确的。
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?

如果我将所需的共享库从主机复制到目标上存储可执行文件的目录,程序仍然无法找到共享库。只有当我将所需的.so文件的副本放在目标上的/ usr / lib /文件夹中时,程序才会运行。运行可执行文件时搜索共享库的文件夹是什么?为什么不在自己的本地文件夹中找到共享库?
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?

当我向项目中添加更多库时,管理它们的最佳方法是什么,并将它们放在目标上。我真的不想在我的主机上下载源代码,交叉编译arm,然后筛选生成的所有库,只传输我需要的骨骼上的.so文件。为目标提供可执行文件所需的库的正确方法是什么?是否有工具/插件来管理或使此过程自动化?
How can I determine what are the required libraries irrespective of all the libraries I added to the eclipse linker?

无论我添加到eclipse链接器的所有库,我如何确定所需的库是什么?
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?

如果我想告诉eclipse不使用共享库,我如何更改OpenCV,Curl和修改eclipse的编译脚本,以便使用静态库?
When doing embedded programming, and cross-compiling is it more typical to use shared libraries or static libraries?

在进行嵌入式编程和交叉编译时,更常见的是使用共享库还是静态库?

Thanks for the help.

谢谢您的帮助。

1 个解决方案

#1

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:

/ lib和/ usr / lib是查找共享库的常用位置。您可以通过定义LD_LIBRARY_PATH环境变量将目录添加到动态加载程序的搜索路径:

setenv LD_LIBRARY_PATH /home/me/lib:/home/me/lib2

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. ;-)

我不知道是否有某种工具/插件。我用的是scp。 ;-)

The ldd command will tell you what shared libraries an executable uses.

ldd命令将告诉您可执行文件使用的共享库。

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.

我不知道是否更典型地使用共享库。我通常使用静态库。在我的ELLCC交叉编译器项目中。我用ELLCC来构建自己。生成的静态链接可执行文件实际上小于使用共享库的gcc编译可执行文件。当然,这是一套完全不同的C ++和C标准库。

#1

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.