3

我在将 boost 库链接到我的交叉编译的 c++ 程序时遇到问题。我编写的代码在 Ubuntu 12.04 下与 CodeSourcery 交叉编译,用于 arm-target(Pandaboard,也是 Ubuntu 12.04)。编译没有库的简单测试程序可以正常工作,即使是带有静态库的 OpenCV 也可以正常工作。

但这里是链接 boost 1.52.0 库时的问题:

当与链接boost库(-lboost_thread -lboost_system)交叉编译时,程序编译没有错误,但在目标上执行时,什么也没有发生。

程序没有错误地完成,就好像它从未被执行过一样。

当与 CodeSourcery 交叉编译而不链接 boost 库时:在目标上一切正常。使用 g++ 在本地编译:一切都很好。

出于测试目的,我将代码简化为以下几行:(即使不使用计时功能也会出现错误。只是链接会有所不同)

主文件

#include <iostream>
using namespace std;

#include<boost/chrono.hpp>

int main(int argc, char* argv[]) {

    cout << "!!!this test worked!!!" << endl;

    return 0;
}

链接器命令是(在 Eclipse 之外):

arm-none-linux-gnueabi-g++ -L/home/xy/arm-none-linux-gnueabi/lib -o "testARM" ./src/main.o -lpthread -lboost_thread -lboost_system

boost-libraries 是按照本指南与 CodeSourcery arm-none-linux-gnueabi-g++ 交叉编译的。我将它们全部复制到目标到 /usr/lib 文件夹中,并将 /usr/lib 添加到 PATH 和 LD_LIBRARY_PATH。

我尝试使用 Eclipse 进行远程调试,结果相同:启动程序..程序以 1 终止。但什么也没发生。

它甚至不会打印错误或抱怨丢失的东西。所以到现在为止,我想不出更多我可以用谷歌搜索的东西,我还没有尝试过......

你能给我任何提示我可以尝试解决这个问题吗?

提前谢谢了!


更新:

使用 strace 运行我的测试程序时,日志包含以下信息:

    $ vi strace-testARM.log
    22:23:56.511385 execve("./testARM", ["./testARM"], [/* 17 vars */]) = 0
    22:23:56.512789 brk(0) = 0xfae000
    22:23:56.512972 uname({sys="Linux", node="panda", ...}) = 0
    22:23:56.514010 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT(没有这样的文件或目录)
    22:23:56.514315 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f9b000
    22:23:56.514498 access("/etc/ld.so.preload", R_OK) = -1 ENOENT(没有这样的文件或目录)
    22:23:56.514742 打开(“/etc/ld.so.cache”,O_RDONLY|O_CLOEXEC)= 3
    22:23:56.514986 fstat64(3, {st_mode=S_IFREG|0644, st_size=52288, ...}) = 0
    22:23:56.515353 mmap2(NULL, 52288, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f72000
    22:23:56.515536​​ 关闭(3)= 0
    22:23:56.515688 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.515902 打开(“/lib/arm-linux-gnueabihf/libpthread.so.0”,O_RDONLY|O_CLOEXEC)= 3
    22:23:56.516207 读取(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\ 0\5P\0\0004\0\0\0"..., 512) = 512
    22:23:56.516451 lseek(3, 66332, SEEK_SET) = 66332
    22:23:56.516573 读取(3,“\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0"..., 1400) = 1400
    22:23:56.516787 lseek(3, 65924, SEEK_SET) = 65924
    22:23:56.516909 读(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n \4\22"..., 55) = 55
    22:23:56.517153 fstat64(3, {st_mode=S_IFREG|0755, st_size=100802, ...}) = 0
    22:23:56.517519 mmap2(NULL, 107024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f57000
    22:23:56.517642 mprotect(0xb6f67000, 28672, PROT_NONE) = 0
    22:23:56.517794 mmap2(0xb6f6e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb6f6e000
    22:23:56.517977 mmap2(0xb6f70000, 4624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f70000
    22:23:56.518160 关闭 (3) = 0
    22:23:56.518313 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.518557 open("/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.518832 stat64("/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp", 0xbea34ea8) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.519076 open("/lib/arm-linux-gnueabihf/tls/v7l/neon/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (没有这样的文件
... [许多其他目录未找到文件] ...
    22:23:56.545382 stat64("/usr/lib/neon/vfp", 0xbea34ea8) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.545565 open("/usr/lib/neon/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.545748 stat64("/usr/lib/neon", 0xbea34ea8) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.545932 open("/usr/lib/vfp/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.546115 stat64("/usr/lib/vfp", 0xbea34ea8) = -1 ENOENT (没有这样的文件或目录)
    22:23:56.546298 打开(“/usr/lib/libboost_thread.so.1.52.0”,O_RDONLY|O_CLOEXEC)= 3
    22:23:56.546481 读取(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\ 0\324\331\0\0004\0\0\0"..., 512) = 512
    22:23:56.546755 lseek(3, 121020, SEEK_SET) = 121020
    22:23:56.546878 读(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0"..., 1200) = 1200
    22:23:56.547091 lseek(3, 119052, SEEK_SET) = 119052
    22:23:56.547213 读(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4 \24\1\25"..., 41) = 41
    22:23:56.547396 exit_group(1) = ?


更新 2:

我正在 Ubuntu 主机上编译我的程序,将文件传输到 Pandaboard 并按照@ShaunMarko 的建议发出以下命令:

`ldd testARM` =>  `not a dynamic executable`

`file testARM` => `testARM: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped`

`file libboost_thread.so.1.52.0` => `libboost_thread.so.1.52.0: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped`

添加-v -H到我收到的编译 g++ 表达式中:

... /xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/include/boost/utility/result_of.hpp

COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-H' '-MMD' '-MP' '-MF' 'main.d' '-MT' 'main.d' '-o' 'main.o' '-shared-libgcc' '-march=armv5te' '-mtls-dialect=gnu' '-funwind-tables' '-D' '__CS_SOURCERYGXX_MAJ__=2012' '-D' '__CS_SOURCERYGXX_MIN__=9' '-D' '__CS_SOURCERYGXX_REV__=64'
 /xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/as -v -march=armv5te -meabi=5 -o main.o /tmp/cceTwLmn.s
GNU assembler version 2.23.51 (arm-none-linux-gnueabi) using BFD version (Sourcery CodeBench Lite 2012.09-64) 2.23.51.20120829
COMPILER_PATH=/xy/CodeSourcery/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/CodeSourcery/bin/../libexec/gcc/:/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/
LIBRARY_PATH=/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/CodeSourcery/bin/../lib/gcc/:/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/lib/:/xy/CodeSourcery/bin/../arm-none-linux-gnueabi/libc/lib/:/xy/CodeSourcery/bin/../arm-none-linux-gnueabi/libc/usr/lib/
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-H' '-MMD' '-MP' '-MF' 'main.d' '-MT' 'main.d' '-o' 'main.o' '-shared-libgcc' '-march=armv5te' '-mtls-dialect=gnu' '-funwind-tables' '-D' '__CS_SOURCERYGXX_MAJ__=2012' '-D' '__CS_SOURCERYGXX_MIN__=9' '-D' '__CS_SOURCERYGXX_REV__=64'

**** Build Finished ****

(这是最后一部分,上面列出了大量包含的标题。xy-Path 是 CodeSourcery 安装在我的主目录中的位置)

4

1 回答 1

3

构建 ARM 应用程序的一般规则(事实上它必须适用于任何平台)

您必须使用相同的 ABI 编译整个程序,并与一组兼容的库链接。

在您的情况下,最后一项看起来像/usr/lib/libboost_thread.so.1.52.0,并且由于它也与您的使用有关,因此请确保libboost_thread与您正在交叉编译的主机上的一项相匹配。

22:23:56.546298 open("/usr/lib/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = 3
22:23:56.546481 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324\331\0\0004\0\0\0"..., 512) = 512
22:23:56.546755 lseek(3, 121020, SEEK_SET) = 121020
22:23:56.546878 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1200) = 1200
22:23:56.547091 lseek(3, 119052, SEEK_SET) = 119052
22:23:56.547213 read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) = 41
22:23:56.547396 exit_group(1)           = ?

对于ARM系统,您可以拥有许多库变体,例如不同的 ABI 或 VFP/NEON 支持,并且获得现成的工具链可能与您默认的目标不匹配,因为它是针对 ARM 的。

更新

如果您检查以前的日志

22:23:56.515902 open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
22:23:56.516207 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\5P\0\0004\0\0\0"..., 512) = 512
22:23:56.516451 lseek(3, 66332, SEEK_SET) = 66332
22:23:56.516573 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1400) = 1400
22:23:56.516787 lseek(3, 65924, SEEK_SET) = 65924
22:23:56.516909 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55

您看到两件事,首先您的系统hf来自路径。在读取的数据中,我们还看到7-A,这可能意味着 ARMv7-A,而5TE这可能意味着来自 libboost_thread 库的 ARMv5TE。您应该使用工具链中的 readelf 来获取有关 elf 文件的信息,而不是使用文件实用程序。

我会尝试编译 boost-march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard并将生成的二进制文件放在`/usr/lib/vfp.

I think reading vfp stuff from Debian site can help you greatly and you should make small exercises yourself, instead of dealing with compilation process of boost to understand the situation.

于 2013-01-24T09:40:21.170 回答