执行二进制文件：找不到文件

9

我知道那里也有类似的问题，但是我还没有找到解决方案，也没有确切的案例。该二进制文件是在Arch Linux上使用其GCC 4.7构建的。该软件包在构建系统上可以正常工作。以下命令在以下位置执行：

Linux vbox-ubuntu 3.2.0-29-generic＃46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

有关文件位于此处。它是Linux 64位到Windows 64位交叉编译器。将其解压缩到~/一个~/mingw64包含所需内容的目录。

当我尝试运行时~/mingw64/x86_64-w64-mingw32/bin/as，我得到的是：

bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory

跑步file ~/mingw64/x86_64-w64-mingw32/bin/as给我：

/home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped

跑步ldd ~/mingw64/x86_64-w64-mingw32/bin/as给我：

    linux-vdso.so.1 =>  (0x00007fff3e367000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000)
    /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000)

我真的很茫然。任何帮助深表感谢。

编辑：更多详细信息：构建系统是Arch Linux（当前为glibc 2.16）。输出ls -l为：

-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as

输出objdump -p为：

Version References:
  required from libz.so.1:
    0x0827e5c0 0x00 05 ZLIB_1.2.0
  required from libc.so.6:
    0x0d696917 0x00 06 GLIBC_2.7
    0x06969194 0x00 04 GLIBC_2.14
    0x0d696913 0x00 03 GLIBC_2.3
    0x09691a75 0x00 02 GLIBC_2.2.5

ldd -v在Ubuntu 12.04上的输出为：

    linux-vdso.so.1 =>  (0x00007fff225ff000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000)

Version information:
/home/ruben/mingw64/x86_64-w64-mingw32/bin/as:
    libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1
    libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libz.so.1:
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

经过测试的其他操作系统是Fedora 17（glibc 2.15）和Ubuntu 12.04（eglibc 2.15）。同时满足zlib和glibc版本要求。

ubuntu  files  compiling  binary  patchelf 
— 红宝石
source
它只是一个错字，还是您实际上是在尝试运行'〜/ mingw64 / x86_64-w64-mingw32 / as'...缺少“ bin”文件夹。
— 2012年
@tripledes类型，并更正。
— rubenvb 2012年
很奇怪，只是尝试下载，在我的〜下解压缩，我得到了预期的结果。您能否提供ls -l〜/ mingw64 / x86_64-w64-mingw32 / bin / as？
— 2012年
1
可能是libc版本不匹配吗？尝试运行“ objdump -p <path / to / as>”并检查“版本引用”部分。看起来好像取决于GLIBC_2.14一样，这可能还算新。您的系统版本是什么？“ readelf -a <path / to / as> | less”和GLIBC的grep，您会看到它使用的是2.14版本的memcpy。我不知道为什么在不同的库调用之间版本会如此之大。
— svenx 2012年

Answers:

8

如果我ldd -v as在系统上运行，则会得到：

./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as)
        linux-vdso.so.1 =>  (0x00007fff89ab1000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000)
        /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000)

是的，看起来这些二进制文件正在寻找GLIBC_2.14符号，您可能在系统上找不到该符号。就像svenx指出的那样，它似乎在寻找memcpy@@GLIBC_2.14符号。此错误报告中memcpy描述了有关为什么要使用新版本的更多信息。

glibc在目标系统上安装的新版本应予以修复。如果您想尝试重建二进制文件以继续在旧版本上运行glibc，则可以尝试使用此处列出的技巧。您也许还可以通过仅提供所需memcpy符号特定版本的填充程序来完成任务，但这有点笨拙。

看完更新后：您是对的，那不是您的问题。但是我想我已经找到了：您的二进制文件正在请求解释器/lib/ld-linux-x86-64.so.2，而该解释器在Ubuntu 12.04系统上不存在：

$ readelf -a ./as | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

虽然ldd知道可以找到它，/lib64但是我想内核不知道它在尝试运行二进制文件时找不到文件的请求解释器。您可以尝试通过解释器手动运行它：

$ pwd
/home/jim/mingw64/x86_64-w64-mingw32/bin
$ ./as --version
-bash: ./as: No such file or directory
$ /lib64/ld-linux-x86-64.so.2 ./as --version
GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

我不是100％肯定这工作正常-在我的系统上，以gcc这种方式运行会产生分段错误。但这至少是一个不同的问题。

— 吉姆·巴黎
source
1
如果是这样的话，那会很好。查看更新:(
— rubenvb 2012年
我已经更新了答案。
— 吉姆·巴黎
哇好 这种糟透了。我想不出一种解决此问题的不错的方法（并继续在Arch上构建）。你有什么好主意吗？
— rubenvb 2012年
1
并不是的。Arch只是愚蠢的- 文件系统继承标准明确指出，库应该位于/lib64amd64上，显然Arch手动修补了其gcc源以更改此设置，从而保证了与其他Linux发行版的不兼容性。请参阅此错误报告的注释，以了解其奇怪的理由。对我来说，这将是远离Arch Linux的明确警告信号。
— 吉姆·巴黎
1
也就是说，您可以使用patchelf更改解释器的位置。有关遇到此问题的另一个人的信息，请参阅此文章，他声称patchelf对他们有用。
— 吉姆·巴黎
0

您的问题是在64位系统上运行32位二进制文​​件时出现“未找到”消息的一种变体：您有一个可执行文件，其中提到了动态加载器，该加载器不存在。

在您的情况下，动态加载程序/lib/ld-linux-x86-64.so.2存在但位于不同的位置/lib64/ld-linux-x86-64.so.2。使程序正常工作的最简单方法是创建一个符号链接：

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/
— 吉尔斯（Gillles）
source
好吧，因为这是一个用于重新分发的程序包，所以这样的符号链接实际上并不是我的控制范围。我以为Linux二进制文件将更具可移植性……猜不到。
— rubenvb 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.