bash：.a.out：在由ld生成的运行可执行文件上没有这样的文件或目录。

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

其他答案仅涉及如何避免这种情况，而不是 实际发生的问题 。

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"], []) = -1 ENOENT (No such file or directory)

execve(2)

返回ENOENT，因为它找不到解释器（我从中找出了解释器

file

，依此类推，请参见下文）。从尝试运行以开头的文件时，您会得到相同的错误

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

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

---

我在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的评论指出了这一点。）