链接Boost库,当程序退出而不会出现错误 [英] program exits without error when linking boost library

查看:204
本文介绍了链接Boost库,当程序退出而不会出现错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有Boost库链接到我的交叉编译的C ++程序有问题。
在code我写的是交叉编译的Ubuntu 12.04与下codeSourcery一个臂目标(PANDABOARD,也Ubuntu的12.04)。
编译简单的测试程序,而无需库工作正常,甚至与OpenCV的静态库工作正常。

但这里是连接升压1.52.0库时的问题:

当连接Boost库(-lboost_thread -lboost_system)程序编译没有错误,但在目标执行时,它crosscompiled,什么都不会发生。

程序没有错误,就好像它根本就不会被执行完成。

在与codeSourcery crosscompiled不链接Boost库:一切正常目标。
与G ++本地编译:样样精以及

有关测试的目的,我剥了下来我的code以下几行:
(错误,即使出现时不使用计时功能。只是链接,使差)

的main.cpp

 的#include<&iostream的GT;
使用命名空间std;#包括LT&;升压/ chrono.hpp>INT主(INT ARGC,CHAR *的argv []){    COUT<< !!!这个测试工作! << ENDL;    返回0;
}

链接器命令(出日食):

  ARM-NONE-Linux的gnueabi-G ++ -L /家庭/ XY / ARM-NONE-Linux的gnueabi / lib目录-otestARM./src/main.o  - lpthread -lboost_thread -lboost_system

升压库进行交叉编译codeSourcery臂无-Linux的gnueabi-G ++下的本指南
我他们全部复制到目标到/ usr / lib文件夹,并添加/ usr / lib目录到PATH和LD_LIBRARY_PATH。

我试图远程调试Eclipse和其一样的:启动程序。程序终止1。
但没有happend。

它并不甚至打印错误或抱怨缺少些什么。
所以,现在我想不出什么更多我可以谷歌,我还没有试过...

您能给我任何暗示什么,我可以尝试解决这一问题?

提前感谢!


更新:

在与strace的运行我的测试程序,日志包含以下信息:

    $六strace的,testARM.log
    22:23:56.511385的execve(./ testARM,[./testARM],[/ * 17 *瓦尔/)= 0
    22:23:56.512789 brk的(0)= 0xfae000
    22:23:56.512972的uname({SYS =Linux的节点=熊猫,...})= 0
    22:23:56.514010访问(在/ 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访问(在/ 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访问(在/ 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访问(在/ etc / ld.so.nohwcap,F_OK)= -1 ENOENT(没有这样的文件或目录)
    22:23:56.518557开(/ lib目录/ ARM-Linux的gnueabihf / TLS / v7l /霓虹灯/ VFP / libboost_thread.so.1.52.0,O_RDONLY | O_CLOEXEC)= -1 ENOENT(没有这样的文件或目录)
    22:23:56.518832 stat64中(/ lib目录/ ARM-Linux的gnueabihf / TLS / v7l /霓虹灯/ VFP,0xbea34ea8)= -1 ENOENT(没有这样的文件或目录)
    22:23:56.519076开(/ lib目录/ ARM-Linux的gnueabihf / TLS / v7l /霓虹灯/ libboost_thread.so.1.52.0,O_RDONLY | O_CLOEXEC)= -1 ENOENT(没有这样的文件
... [与很多其他的文件目录中没有发现] ...
    22:23:56.545382 stat64中(/ usr / lib目录/霓虹灯/ VFP,0xbea34ea8)= -1 ENOENT(没有这样的文件或目录)
    22:23:56.545565开(/ usr / lib目录/霓虹灯/ libboost_thread.so.1.52.0,O_RDONLY | O_CLOEXEC)= -1 ENOENT(没有这样的文件或目录)
    22:23:56.545748 stat64中(/ usr / lib目录/霓虹灯,0xbea34ea8)= -1 ENOENT(没有这样的文件或目录)
    22:23:56.545932开(/ 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` => `不是动态executable``文件testARM` => `testARM:ELF 32位LSB的可执行文件,ARM版本1(SYSV),动态链接(使用共享库),为GNU / Linux 2.6.16,而不是stripped``文件libboost_thread.so.1.52.0` => `libboost_thread.so.1.52.0:ELF 32位LSB的共享对象,ARM版本1(SYSV),动态链接,不stripped`

添加 -v -H 来编译g ++的前pression我收到:

  ... /xy/$c$cSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/include/boost/utility/result_of.hppCOLLECT_GCC_OPTIONS =' -  O0'-g3'-Wall'-c'-fmessage长度= 0''-v'-H'-MMD'-MP'-MF'main.d ''-MT''main.d''-o''main.o中'-shared-libgcc的'-march =的ARMv5TE'-mtls方言= GNU''-funwind桌'-D'' __CS_SOURCERYGXX_MAJ __ = 2012''-D'__CS_SOURCERYGXX_MIN __ = 9''-D'__CS_SOURCERYGXX_REV __ = 64'
 /xy/$c$cSourcery/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
使用BFD版本的GNU汇编版本51年2月​​23日(ARM-NONE-Linux的gnueabi)(的Sourcery codeBench精简版2012.09-64)2.23.51.20120829
COMPILER_PATH=/xy/$c$cSourcery/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/$c$cSourcery/bin/../libexec/gcc/:/xy/$c$cSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/
LIBRARY_PATH=/xy/$c$cSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/$c$cSourcery/bin/../lib/gcc/:/xy/$c$cSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/lib/:/xy/$c$cSourcery/bin/../arm-none-linux-gnueabi/libc/lib/:/xy/$c$cSourcery/bin/../arm-none-linux-gnueabi/libc/usr/lib/
COLLECT_GCC_OPTIONS =' - O0'-g3'-Wall'-c'-fmessage长度= 0''-v'-H'-MMD'-MP'-MF'main.d ''-MT''main.d''-o''main.o中'-shared-libgcc的'-march =的ARMv5TE'-mtls方言= GNU''-funwind桌'-D'' __CS_SOURCERYGXX_MAJ __ = 2012''-D'__CS_SOURCERYGXX_MIN __ = 9''-D'__CS_SOURCERYGXX_REV __ = 64'****建立成品****

(这是最后一部分,上面有上市吨包含头文件。在XY-Path是其中codeSourcery安装在我的主目录)


解决方案

构建ARM应用程序(实际上它必须是任何平台真)一般规则


  

    

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


  

在您的情况下,最后一个项目看起来像 /usr/lib/libboost_thread.so.1.52.0 键,因为这也关系到您的使用情况,确保 libboost_thread 匹配你是交叉编译的主机上的之一。

  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)=?

使用 ARM 系统,您可以有像不同的ABI或VFP / NEON支持,并得到一个现成的工具链可能不符合你默认目标库的许多变种只是因为它是ARM。

更新

如果您检查previous日志

  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

您看到两件事,一是你的系统是 HF 从路径。在读取数据时,我们也看到 7-A 相比, 5TE 这可能意味着的ARMv7-A这可能意味着可用于A​​RMv5TE从libboost_thread库。您应该使用readelf从你的工具链,以获取有关ELF文件,而不是文件的实用程序的信息。

我会尝试编译加强与 -march =的ARMv7-A -mfpu =的VFPv3-D16 -mfloat-ABI =硬,并把生成的二进制下是`/ usr / lib目录/ VFP。

我觉得阅读 VFP的东西从Debian的网站可以极大地帮助你,你应该做小运动你自己,而不是使用增强的编译过程打交道了解情况。

I have a problem with linking boost library into my cross-compiled c++ program. The code I write is cross-compiled with CodeSourcery under Ubuntu 12.04 for an arm-target (Pandaboard, also Ubuntu 12.04). Compiling simple test-programs without library works fine, even OpenCV with static libraries works fine.

But here is the problem when linking boost 1.52.0 libraries:

When crosscompiled WITH linking boost libraries (-lboost_thread -lboost_system) the program compiles without errors, but when executing it on target, nothing happens.

Program finishes without error as if it would have never been executed.

When crosscompiled with CodeSourcery WITHOUT linking boost libraries: everything works fine on target. Compiled locally with g++: everything fine as well.

For testing purposes i stripped down my code to the following few lines: (error even appears when no chrono-function is used. just linking makes the difference)

main.cpp

#include <iostream>
using namespace std;

#include<boost/chrono.hpp>

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

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

    return 0;
}

Linker command is (out of eclipse):

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

The boost-libraries were cross-compiled with CodeSourcery arm-none-linux-gnueabi-g++ following this guide. I copied them all to the target into /usr/lib folder and added /usr/lib to PATH and to LD_LIBRARY_PATH.

I tried remote debugging with eclipse and its the same: starting program.. program terminated with 1. But nothing happend.

It doesnt even print an error or complain about something missing. So by now I cant think of anything more I could google that I havent tried...

Could you give me any hints what I could try to fix this?

Many thanks in advance!


Update:

When running my test program with strace, the log contains following info:


    $ 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 (No such file or directory)
    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 (No such file or directory)
    22:23:56.514742 open("/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 close(3)                = 0
    22:23:56.515688 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
    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
    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 close(3)                = 0
    22:23:56.518313 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
    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 (No such file or directory)
    22:23:56.518832 stat64("/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp", 0xbea34ea8) = -1 ENOENT (No such file or directory)
    22:23:56.519076 open("/lib/arm-linux-gnueabihf/tls/v7l/neon/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
... [ lots of other directories with file not found ] ...
    22:23:56.545382 stat64("/usr/lib/neon/vfp", 0xbea34ea8) = -1 ENOENT (No such file or directory)
    22:23:56.545565 open("/usr/lib/neon/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    22:23:56.545748 stat64("/usr/lib/neon", 0xbea34ea8) = -1 ENOENT (No such file or directory)
    22:23:56.545932 open("/usr/lib/vfp/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    22:23:56.546115 stat64("/usr/lib/vfp", 0xbea34ea8) = -1 ENOENT (No such file or directory)
    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)           = ?


Update 2:

I am compiling my program on an Ubuntu Host, transfer the file onto the Pandaboard and issue the following commands as suggested by @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`

Adding -v -H to the compiling g++ expression I receive:

... /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 ****

(This is the last part, above that there are listed tons of included headers. The xy-Path is where CodeSourcery is installed in my home directory)

解决方案

General rule for building ARM applications (in fact it must be true for any platform)

You must compile your entire program with the same ABI, and link with a compatible set of libraries.

In your case last item looks like /usr/lib/libboost_thread.so.1.52.0 and since it is also related to your usage, be sure that libboost_thread matches the one on the host that you are cross compiling.

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)           = ?

With ARM systems you can have many variants of a library like different ABIs or VFP/NEON support and getting an off the shelf toolchain might not match what you target by default just because it is for ARM.

update

If you check a previous log

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

You see two things, first your system is hf from the path. In the read data we also see 7-A, which probably means ARMv7-A compared to 5TE which probably means ARMv5TE from your libboost_thread library. You should use readelf from your toolchain to get information about elf files instead of file utility.

I would try to compile boost with -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard and put the resulting binary under `/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.

这篇关于链接Boost库,当程序退出而不会出现错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆