gcc arm可执行文件“;“没有此类文件或目录”;,错误的动态库

gcc arm可执行文件“;“没有此类文件或目录”;,错误的动态库,gcc,Gcc,我试图在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工具链,它使用自己的

我试图在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 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
战略日志:

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 +++

我可以想到以下几点,因为我以前也遇到过类似的问题

arm发行版在其发行版或其他文件夹中的/usr/lib或/lib等文件夹中具有所需的库,而您的编译环境在不同的位置具有这些库。如果是这样,那么

  • 使用ld_library_path环境变量(或.bashrc)设置库路径可能会有所帮助
  • 或者创建与系统中相同的文件夹结构也可能有所帮助
我可以看出,您的交叉编译没有考虑任何特定于硬件的库,但它只是新硬件的系统库,它将是依赖的


当然,我假设您已经完成了chmod,使您的程序成为arm硬件或模拟器中的可执行程序。

它很可能是部署计算机上缺少的共享库

尝试运行
$(CC)-readelf-d您需要的二进制文件| grep
。这将显示所需共享库的名称。验证它们是否存在于目标计算机上

尝试在目标计算机上运行
ldd-you-binary
。它应该报告所需的内容 动态库以及是否已找到它们


另外,在目标机上运行程序时,使用
strace您的二进制文件
。查找
open
access
调用,这些调用返回错误
enoint

我自己解决了,感谢您的支持

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
ln-s/lib/ld-2.16.so/lib/ld-linux-armhf.so.3
-rwxr-xr-x 1根根目录130304 2013年3月20日/lib/ld-2.16.so
lrwxrwx 1 root根目录15 Dec 24 23:14/lib/ld linux armhf.so.3->/lib/ld-2.16.so ld-2.16.so

向所有人致以最诚挚的问候和圣诞快乐,

如果将选项
mfloat abi=hard
添加到
LDFLAGS
链接器中,编译器将使用
ld linux armhf.so.3
加载程序,而不是
ld linux.so.3
。不需要符号链接。至少它解决了我的Yocto Poky工具链的问题。请参见

我尝试在windows for linux Angstrom上交叉编译,是的,我制作了+x:)strace请参见上文(感谢您指点我,优秀的工具)您能帮我了解一些错误吗?似乎缺少/etc/ld.so.preload(或者我的libc只是包含了其中的一些符号)不,ld.so.preload不是严格要求的。我看不出这个strace输出中有任何错误:(该死,我在这上面浪费了几个小时,谢谢。对于在不同工具链上有类似问题的任何人,可以使用“strings”命令检查libs。(strings~/development/test.elf | grep lib/lib/ld linux armhf.so.3 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libc.so.6_libc_____start_main)
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