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

Question

这是 C:

中的 Hello World 代码

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

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

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

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

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

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

我正在运行ning 一台 64 位机器并且运行ning 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 a.c 生成 a.out，其中运行正确。

Answer 1

使用那个：

  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

Answer 2

ld -lc a.o

此命令行有几处错误：

一般来说，用户级代码应该从不直接使用ld，总是使用适当的编译器前端（此处为gcc）执行link.

如您所见，gcc构造的link命令行相当复杂，您在Joan Esteban的回答中接受的命令行是错误的。

如果您想查看 actual link 命令，请检查 gcc -v a.o.
的输出
另请注意，当您仅稍微更改 gcc 命令时，link 命令会发生显着变化（例如，某些 OSes 需要不同的 crt1.o，具体取决于您是否 linking 多线程可执行文件），并且命令行总是 OS-specific（这是从不直接使用 ld 的另一个原因).
库应该跟在命令行上的目标文件之后。所以 ld -lc a.o 永远不会 正确，并且总是应该是 ld a.o -lc 的（变体）。 Explanation.

Answer 3

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

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

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

其他答案只解决如何避免这种情况¹，而不是实际发生的问题。

您给出的 gcc -c a.c; ld -lc a.o 命令产生了一个非常明显的警告：

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) returns ENOENT 因为它找不到解释器（这是我从 file 等中得出的，见下文）。尝试运行以

开头的文件会出现相同的错误

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

如您所见，出现此错误消息的通常原因是运行在没有安装正确的动态 linker 和动态库的系统上安装 ELF 二进制文件（例如，没有安装正确的 64 位系统）安装了 32 位支持）。在你的情况下，这是因为你使用了一个错误的 link 命令并创建了一个带有错误解释器路径的动态可执行文件。

我在 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 headers，包括解释器路径。（感谢@EmployedRussian 指出这一点的评论。）

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

`bash: ./a.out: No such file or directory` on running executable produced by `ld`

c

linux

gcc

linker

dynamic-linking

为什么连执行都执行不了的问题还是很有意思：

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

`bash: ./a.out: No such file or directory` on running executable produced by `ld`

c

linux

gcc

linker

dynamic-linking

为什么连执行都执行不了的问题还是很有意思：

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