我正在尝试在Windows上为gcc-linaro-arm-linux-gnueabihf-4.8-2013.11进行可用的设置。 在动态链接上发生了一些事情：
$(CC)-gcc -o test main.c -Wall -lc
该程序编译良好，但部署到ARM时显示： “没有这样的文件或目录”
搜索问题，似乎静态构建有效，但可执行文件很大：
$(CC)-gcc -static -o test main.c -Wall -lc
现在我安装了一个VisualGDB工具链，用它自己的工具链构建（在IDE中）一个类似的可执行文件（小的，动态的）可以工作，所以我想这对我的ARM发行版没有任何问题。
我是否遗漏了某些错误，包括gcc-linaro-arm-linux-gnueabihf-4.8-2013.11？
非常感谢，
还有一项调查：
file test
working (compiled with VisualGDB toolchain)
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
mot working (compiled with gcc-linaro-arm-linux-gnueabihf-4.8-2013.11)
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.1.1, BuildID[sha1]=0x13accf06af902cd8b96d85b8a412e1d7822a302b, not stripped
my ARM
3.8.13
我运行-readelf（非工作）：
Dynamic section at offset 0x474 contains 24 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000c (INIT) 0x82a0
0x0000000d (FINI) 0x8434
0x00000019 (INIT_ARRAY) 0x10468
0x0000001b (INIT_ARRAYSZ) 4 (bytes)
0x0000001a (FINI_ARRAY) 0x1046c
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x8194
0x00000005 (STRTAB) 0x820c
0x00000006 (SYMTAB) 0x81bc
0x0000000a (STRSZ) 65 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x1055c
0x00000002 (PLTRELSZ) 32 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x8280
0x00000011 (REL) 0x8278
0x00000012 (RELSZ) 8 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x8258
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x824e
0x00000000 (NULL) 0x0
并且正在工作：
Dynamic section at offset 0x4d0 contains 24 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000c (INIT) 0x8274
0x0000000d (FINI) 0x8490
0x00000019 (INIT_ARRAY) 0x104c4
0x0000001b (INIT_ARRAYSZ) 4 (bytes)
0x0000001a (FINI_ARRAY) 0x104c8
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x8168
0x00000005 (STRTAB) 0x81e0
0x00000006 (SYMTAB) 0x8190
0x0000000a (STRSZ) 65 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x105b8
0x00000002 (PLTRELSZ) 32 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x8254
0x00000011 (REL) 0x824c
0x00000012 (RELSZ) 8 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x822c
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x8222
0x00000000 (NULL) 0x0
strace log：
execve("/usr/bin/test", ["test"], [/* 15 vars */]) = 0
brk(0) = 0x17000
uname({sys="Linux", node="beaglebone", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f8a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=54751, ...}) = 0
mmap2(NULL, 54751, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f57000
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0@\321\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1505830, ...}) = 0
mmap2(NULL, 152384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f31000
mprotect(0xb6f4f000, 28672, PROT_NONE) = 0
mmap2(0xb6f56000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d) = 0 xb6f56000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\177\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1205468, ...}) = 0
mmap2(NULL, 1246600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e00000
mprotect(0xb6f24000, 28672, PROT_NONE) = 0
mmap2(0xb6f2b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123) = 0xb6f2b000
mmap2(0xb6f2e000, 9608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb 6f2e000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f89000
set_tls(0xb6f896d0, 0xb6f89da8, 0xb6f8c058, 0xb6f896d0, 0xb6f8c058) = 0
mprotect(0xb6f2b000, 8192, PROT_READ) = 0
mprotect(0xb6f8b000, 4096, PROT_READ) = 0
munmap(0xb6f57000, 54751) = 0
brk(0) = 0x17000
brk(0x38000) = 0x38000
close(1) = 0
close(2) = 0
exit_group(1) = ?
+++ exited with 1 +++
答案 0 :(得分：8)
我自己解决了，无论如何都要感谢你的支持。
来自Linaro的交叉编译器链接了一个新的lib名称（Debian中的一些名称更改），例如/lib/ld-linux-armhf.so.3但BBB（默认）发行版使用旧名称/ lib / LD-linux.so.3。两个名称都应该将BBB上的（符号链接）指向实际使用的库，即ld-2.16.so
所以创建另一个符号链接就是这样。
ln -s /lib/ld-2.16.so /lib/ld-linux-armhf.so.3
-rwxr-xr-x 1 root root 130304 Mar 20 2013 /lib/ld-2.16.so
lrwxrwxrwx 1 root root 15 Dec 24 23:14 /lib/ld-linux-armhf.so.3 -> /lib/ld-2.16.so <-- new one
lrwxrwxrwx 1 root root 10 Jun 19 2013 /lib/ld-linux.so.3 -> ld-2.16.so
祝大家圣诞快乐，
答案 1 :(得分：1)
它可能是部署计算机上缺少的共享库。
尝试运行$(CC)-readelf -d your-binary | grep NEEDED。这将显示所需共享库的名称。验证它们是否存在于目标计算机上
尝试在目标计算机上运行ldd you-binary。它应该报告所需的内容
动态库以及它们是否已被发现。
PS。使用strace your-binary在目标上运行该程序。查找open或access次调用，这些调用会返回错误ENOENT。
答案 2 :(得分：0)
我可以想到以下内容，因为我之前遇到过类似的问题。
arm分发在其发行版或其他文件夹中的/ usr / lib或/ lib文件夹中具有所需的库，并且您的编译环境将这些库放在不同的位置。如果是这种情况，那么
我可以看到你的交叉编译没有考虑任何特定于硬件的库，但它只是它依赖的新硬件系统库。
当然我假设您已经完成了一个chmod，使您的程序在您的arm硬件或模拟器中成为可执行文件。
答案 3 :(得分：0)
如果通过将选项{
"Accept": "application/json",
"Authorization": "Bearer <token>",
"Content-Type": "application/json",
"Prefer": "outlook.timezone=AUS Eastern Standard Time",
"User-Agent": "myApp/1.0",
"client-request-id": "<client-id>",
"return-client-request-id": "true"
}
通过添加到链接器ld-linux-armhf.so.3到链接器，编译器将使用ld-linux.so.3加载器而不是mfloat-abi=hard。无需符号链接。至少它解决了我的Yocto Poky工具链的问题。参见https://github.com/golang/go/issues/12443