“bash：./a.out：'ld`运行的可执行文件上没有这样的文件或目录

这里是一个C世界中的Hello World代码：

// ac #include <stdio.h> int main() { printf("Hello world\n"); return 0; }

我把它编译为gcc ac ，它可以像预期的那样产生a.out ，而./a.out打印出Hello world所期望的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

我GOOGLE了错误，似乎发生在生成的可执行文件是一个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 ，它能够正确运行。

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

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

ld -lc ao

这个命令行有几个错误：

一般来说，用户级代码不应该直接使用ld ，并且总是使用合适的编译器前端（这里是gcc ）来执行链接。

正如你所发现的那样， gcc构建的链接命令行相当复杂，你在Joan Esteban的答案中接受的命令行是错误的。

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

另外请注意，只有稍微更改gcc命令时，link命令会发生显着的变化（例如，某些操作系统需要不同的crt1.o具体取决于您是否连接了多线程可执行文件），并且命令行始终是OS特定的（即更多的理由不要直接使用ld ）。
库应该在命令行上跟踪目标文件。所以ld -lc ao 永远不会是正确的，并且应该总是（ ld ao -lc的变体）。说明。

使用：

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