`bash: ./a.out: 在运行由 `ld` 生成的可执行文件时没有这样的文件或目录

Question

这是一个 C 语言的 Hello World 代码：

// a.c
#include <stdio.h>

int main() {
    printf("Hello world\n");
    return 0;
}

我将它编译为gcc ac ，它按预期生成a.out并且./a.out打印Hello world ... 按预期。

现在，如果我分别进行编译和链接： gcc -c ac; ld -lc ao gcc -c ac; ld -lc ao ，它运行生成为./a.out的a.out我收到消息：

bash: ./a.out: No such file or directory

我在谷歌上搜索了那个错误，当生成的可执行文件是 32 位 ELF 并且机器架构是 64 位时，似乎会发生这种情况。

我正在运行 64 位机器并运行file a.out给出：

a.out: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

为什么会发生这种情况？

编辑：

uname -m输出

$ uname -m
x86_64

ldd a.out输出

$ ldd a.out
    linux-vdso.so.1 =>  (0x00007ffeeedfb000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa13a7b8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa13abab000)

gcc ac生成a.out可以正确运行。

Answer 1

ld -lc ao

这个命令行有几个问题：

1. 通常，用户级代码永远不应该直接使用ld ，而始终使用适当的编译器前端（此处为gcc ）来执行链接。

   如您gcc ， gcc构建的链接命令行非常复杂，您在 Joan Esteban 的回答中接受的命令行是错误的。

   如果您想查看实际的链接命令，请检查gcc -v ao输出。

   另请注意，当您仅稍微更改gcc命令时，链接命令会发生显着变化（例如，某些操作系统需要不同的crt1.o具体取决于您是否链接多线程可执行文件），并且命令行始终是特定于操作系统的（这是一个永远不要直接使用ld更多理由）。

2. 库应该在命令行上遵循目标文件。 所以ld -lc ao永远不会正确，应该总是（变体） ld ao -lc 。 解释。

Answer 2

使用gcc foo.o链接动态可执行文件（为 CRT 和 libc 使用正确的路径，以及动态链接器/ELF 解释器ld-linux-x86-64.so.2 ）。
或者gcc -nostartfiles foo.o用于 libc 而不是 CRT _start ，如果你有一个手写的_start

（对于没有 libc 或 CRT 的静态可执行文件，您可以直接使用ld或gcc -nostdlib -static 。）

gcc -v foo.o将显示您系统上使用的实际 GCC 路径。

---

其他答案只解决如何避免这个问题¹ ，而不是发生了什么的实际问题。

gcc -c ac; ld -lc ao 您给出的gcc -c ac; ld -lc ao命令会产生一个非常明显的警告：

ld: warning: cannot find entry symbol _start; defaulting to 0000000000400260

所以即使这个文件可以被执行，它也可能会立即崩溃。 请参阅@EmployedRussian 的回答以了解您应该做什么。

---

为什么它甚至无法执行的问题仍然很有趣：

$ strace ./a.out 
execve("./a.out", ["./a.out"], [/* 72 vars */]) = -1 ENOENT (No such file or directory)

execve(2)返回 ENOENT 因为它找不到解释器（我从file等中找出来的，见下文）。 尝试运行以

#!/usr/non-existant-path/bin/bash

如您所见，此错误消息的常见原因是在未安装正确动态链接器和动态库的系统上运行 ELF 二进制文件（例如，未安装 32 位支持的 64 位系统）。 在您的情况下，这是因为您使用了错误的链接命令并使用错误的解释器路径制作了动态可执行文件。

---

我在 Ubuntu 15.10 上，其中 GNU file版本 5.22 报告：

a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, not stripped

我的系统上没有/lib/ld64.so.1 。 ldd输出令人困惑，因为ldd使用其默认 ELF 解释器，而不是二进制文件指定的解释器。

$ ldd a.out
        linux-vdso.so.1 =>  (0x00007ffc18d2b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0e0a79f000)
        /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x0000559dbc9d2000)

所以它假设二进制文件中的运行时解释器解析为自己使用的那个ldd ，我猜。

您的ldd输出也可能来自旧版本，因为它只显示该行的/lib64/ld-linux-x86-64.so.2 。 对于像这样的奇怪案例，不进行错误的猜测可能是更好的行为，但不会帮助您了解二进制文件具有奇怪的解释器路径。

readelf -l a.out

将为您解码 ELF 标头，包括解释器路径。 （感谢@EmployedRussian 的评论指出这一点。）

Answer 3

使用那个：

  ld -o a.out -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o -lc c.o /usr/lib/crtn.o