链接boost库时程序退出没有错误 [英] program exits without error when linking boost library
问题描述
我在将 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 使用命名空间标准；#includeint main(int argc, char* argv[]) {cout<<！！！这个测试成功了！！！"<<结束;返回0；} 链接器命令是(在 Eclipse 之外):
arm-none-linux-gnueabi-g++ -L/home/xy/arm-none-linux-gnueabi/lib -o "testARM" ./src/main.o -lpthread -lboost_thread -lboost_systemboost-libraries 与 CodeSourcery arm-none-linux-gnueabi-g++ 交叉编译 本指南.我将它们全部复制到目标到/usr/lib 文件夹中，并将/usr/lib 添加到 PATH 和 LD_LIBRARY_PATH.
我尝试使用 eclipse 进行远程调试，结果相同:启动程序.. 程序以 1 终止.但什么也没发生.
它甚至不会打印错误或抱怨丢失的东西.所以到现在为止我想不出还有什么我可以用谷歌搜索我还没有尝试过的......
你能给我一些提示，我可以尝试解决这个问题吗?
非常感谢！
<小时>更新:
使用 strace 运行我的测试程序时，日志包含以下信息:
<前>$ vi strace-testARM.log22:23:56.511385 execve("./testARM", ["./testARM"], [/* 17 vars */]) = 022:23:56.512789 brk(0) = 0xfae00022:23:56.512972 uname({sys="Linux", node="panda", ...}) = 022: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) = 0xb6f9b00022:23:56.514498 访问(/etc/ld.so.preload"，R_OK)= -1 ENOENT(没有这样的文件或目录)22:23:56.514742 打开(/etc/ld.so.cache"，O_RDONLY|O_CLOEXEC)= 322:23:56.514986 fstat64(3, {st_mode=S_IFREG|0644, st_size=52288, ...}) = 022:23:56.515353 mmap2(NULL, 52288, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f7200022:23:56.515536 关闭(3)= 022: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)= 322: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) = 51222:23:56.516451 lseek(3, 66332, SEEK_SET) = 6633222: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) = 140022:23:56.516787 lseek(3, 65924, SEEK_SET) = 6592422: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) = 5522:23:56.517153 fstat64(3, {st_mode=S_IFREG|0755, st_size=100802, ...}) = 022:23:56.517519 mmap2(NULL, 107024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f5700022:23:56.517642 mprotect(0xb6f67000, 28672, PROT_NONE) = 022:23:56.517794 mmap2(0xb6f6e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb6f6e00022:23:56.517977 mmap2(0xb6f70000, 4624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f7000022:23:56.518160 关闭(3)= 022:23:56.518313 访问(/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)= 322: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) = 51222:23:56.546755 lseek(3, 121020, SEEK_SET) = 12102022: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) = 120022:23:56.547091 lseek(3, 119052, SEEK_SET) = 11905222: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) = 4122:23:56.547396 exit_group(1) = ?<小时>
更新 2:
我正在 Ubuntu 主机上编译我的程序，将文件传输到 Pandaboard 并按照@ShaunMarko 的建议发出以下命令:
`ldd testARM` =>`不是动态可执行文件``文件 testARM` =>`testARM:ELF 32 位 LSB 可执行文件，ARM，版本 1 (SYSV)，动态链接(使用共享库)，用于 GNU/Linux 2.6.16，未剥离``文件 libboost_thread.so.1.52.0` =>`libboost_thread.so.1.52.0:ELF 32 位 LSB 共享对象，ARM，版本 1 (SYSV)，动态链接，未剥离`将 -v -H 添加到我收到的编译 g++ 表达式中:
.../xy/CodeSourcery/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-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.sGNU 汇编器版本 2.23.51 (arm-none-linux-gnueabi) 使用 BFD 版本 (Sourcery CodeBench Lite 2012.09-64) 2.23.51.20120829COMPILER_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'**** 构建完成 ****(这是最后一部分，上面列出了大量包含的标题.xy-Path 是 CodeSourcery 安装在我的主目录中的位置)
构建 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) = 322: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) = 51222:23:56.546755 lseek(3, 121020, SEEK_SET) = 12102022: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) = 120022:23:56.547091 lseek(3, 119052, SEEK_SET) = 11905222: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) = 4122: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) = 322: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) = 51222:23:56.516451 lseek(3, 66332, SEEK_SET) = 6633222: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) = 140022:23:56.516787 lseek(3, 65924, SEEK_SET) = 6592422: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，这可能意味着 ARMv7-A，而 5TE 可能意味着来自 libboost_thread 库的 ARMv5TE.您应该使用工具链中的 readelf 来获取有关 elf 文件的信息，而不是文件实用程序.
我会尝试使用 -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard 编译 boost，并将生成的二进制文件放在`/usr/lib/vfp 下.
我认为从 Debian 站点阅读 vfp 的东西 可以对你有很大帮助，你应该做一些小练习自己，而不是处理boost的编译过程来了解情况.
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屋！
