GCC Arm 可执行文件"no such file orr directory"，错误的动态库

我正在尝试在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

跟踪日志：

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, "177ELF1113(1@321004"..., 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, "177ELF1113(12101771004"..., 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 +++

我自己解决了，无论如何感谢您的支持。

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

向大家致以最诚挚的问候和圣诞快乐，

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

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

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

使用strace your-binary在目标上运行程序。查找返回错误ENOENT的open或access调用。

如果通过将

选项mfloat-abi=hard传递给链接器，编译器将使用LDFLAGS，则编译器使用ld-linux-armhf.so.3加载程序而不是ld-linux.so.3。不需要符号链接。至少它解决了我的Yocto Poky工具链的问题。见 https://github.com/golang/go/issues/12443

我可以想到以下内容，因为我之前遇到了一些类似的问题。

arm 发行版在其发行版或其他文件夹中（如/usr/lib 或/lib）中具有所需的库，并且您的编译环境将这些库放在不同的位置。如果是这种情况，那么要么

使用环境变量（或 .bashrc）设置库路径可能会有所帮助ld_library_path
或者创建与系统中相同的文件夹结构也可能有所帮助

我可以看到您的交叉编译没有考虑任何特定于硬件的库，但它只是新硬件的系统库，它将依赖于它。

当然，我假设您已经做了一个chmod来使您的程序成为Arm硬件或模拟器中的可执行文件。

相关内容

最新更新

热门标签：