我在将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 ++本地编译:一切都很好。
出于测试目的,我将我的代码删除到以下几行: (当没有使用计时功能时,甚至会出现错误。只是链接会产生差异)
的main.cpp
#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
在this guide之后,使用CodeSourcery arm-none-linux-gnueabi-g ++交叉编译了boost-libraries。 我将它们全部复制到目标到/ usr / lib文件夹中,并将/ usr / lib添加到PATH和LD_LIBRARY_PATH。
我尝试使用eclipse进行远程调试及其相同:启动程序..程序终止于1。 但没有任何事情发生。
它甚至不会打印错误或抱怨缺少的东西。 所以到现在为止我还想不到任何我可以google的东西,我还没试过......
你可以给我一些提示,我可以尝试解决这个问题吗?
非常感谢提前!
更新
使用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 (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) = ?
更新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的地方)
答案 0 :(得分: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文件的信息,而不是文件实用程序。
我会尝试使用-march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard
编译boost并将生成的二进制文件放在`/ usr / lib / vfp。
我认为从Debian网站阅读vfp stuff可以帮助你,你应该自己做一些小练习,而不是处理提升的编译过程以了解情况。