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

前端之家收集整理的这篇文章主要介绍了`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

我用Google搜索了这个错误,似乎当生成的可执行文件是32位ELF并且机器架构是64位时会发生这种情况.

我正在运行64位机器并运行文件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.

其他答案只涉​​及如何避免这种情况,而不是实际发生的问题.

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)返回ENOENT,因为它找不到解释器(我从文件中找到了等等,见下文).尝试运行以开头的文件时,您会收到同样的错误

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

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

我在Ubuntu 15.10上,GNU文件版本5.22报告:

a.out: ELF 64-bit LSB executable,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相关文章