bash:./a.out:在由ld生成的运行可执行文件上没有这样的文件或目录。
这是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
。
现在,如果我分别进行编译和链接: 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
正确运行。
回答:
其他答案仅涉及如何避免这种情况,而不是 。
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.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的评论指出了这一点。)
以上是 bash:./a.out:在由ld生成的运行可执行文件上没有这样的文件或目录。 的全部内容, 来源链接: utcz.com/qa/430707.html