其他答案仅涉及如何避免这种情况，而不是 。
gcc -c a.c; ld -lc a.o您提供的命令会产生非常明显的警告：
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400260
因此，即使可以执行该文件，它也可能立即崩溃。 ，以获取有关应该执行的操作的说明。
为什么甚至无法执行该问题仍然很有趣：$ 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
如您所发现，此错误消息的通常原因是在没有安装正确的动态链接器和动态库的系统（例如，未安装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.outlinux-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的评论指出了这一点。）
解决方法这是C语言中的Hello World代码：
// a.c#include <stdio.h>int main() { printf('Hello worldn'); return 0;}
我将其编译为gcc a.c，生成a.out预期的结果并按预期方式./a.out打印Hello world。
现在，如果我分别进行编译和链接： gcc -c a.c; ld -lc a.o，它将在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 -mx86_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正确运行。
