我想启动wine
可执行文件(版本 2.12),但出现以下错误($
=shell 提示符):
$ wine
bash: /usr/bin/wine: No such file or directory
$ /usr/bin/wine
bash: /usr/bin/wine: No such file or directory
$ cd /usr/bin
$ ./wine
bash: ./wine: No such file or directory
但是,该文件就在那里:
$ which wine
/usr/bin/wine
可执行文件肯定存在并且没有死符号链接:
$ stat /usr/bin/wine
File: /usr/bin/wine
Size: 9712 Blocks: 24 IO Block: 4096 regular file
Device: 802h/2050d Inode: 415789 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-07-13 13:53:00.000000000 +0200
Modify: 2017-07-08 03:42:45.000000000 +0200
Change: 2017-07-13 13:53:00.817346043 +0200
Birth: -
它是一个 32 位 ELF:
$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped
我可以获得可执行文件的动态部分:
$ readelf -d /usr/bin/wine
Dynamic section at offset 0x1efc contains 27 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libwine.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000001d (RUNPATH) Library runpath: [$ORIGIN/../lib32]
0x0000000c (INIT) 0x7c000854
0x0000000d (FINI) 0x7c000e54
[more addresses without file names]
但是,我无法使用以下命令列出共享对象依赖项ldd
:
$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory
strace
显示:
execve("/usr/bin/wine", ["wine"], 0x7fff20dc8730 /* 66 vars */) = -1 ENOENT (No such file or directory)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
getpid() = 23783
exit_group(1) = ?
+++ exited with 1 +++
编辑添加@jww的建议:问题似乎发生在请求动态链接库之前,因为没有ld
生成调试消息:
$ LD_DEBUG=all wine
bash: /usr/bin/wine: No such file or directory
即使只打印 的可能值LD_DEBUG
,也会出现错误
$ LD_DEBUG=help wine
bash: /usr/bin/wine: No such file or directory
编辑添加@Raman Sailopal 的建议:问题似乎出在可执行文件中,因为将内容复制/usr/bin/wine
到另一个已创建的文件会产生相同的错误
root:bin # cp cat testcmd
root:bin # testcmd --help
Usage: testcmd [OPTION]... [FILE]...
Concatenate FILE(s) to standard output.
[rest of cat help page]
root:bin # dd if=wine of=testcmd
18+1 records in
18+1 records out
9712 bytes (9.7 kB, 9.5 KiB) copied, 0.000404061 s, 24.0 MB/s
root:bin # testcmd
bash: /usr/bin/testcmd: No such file or directory
有什么问题或者我可以做什么来找出丢失的文件或目录?
uname -a
:
Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux
答案1
这:
$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped
与此结合:
$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory
强烈提示系统没有/lib/ld-linux.so.2
ELF解释器。也就是说,这个64位系统没有安装任何32位兼容库。因此,@user1334609 的答案基本上是正确的。
答案2
您正在尝试在 64 位操作系统上运行 32 位应用程序,因此您需要安装 32 位兼容性库(特别是 glibc)才能运行。
答案3
仅供参考,我在基于 alpine 的 docker 镜像中运行时遇到了同样的问题。可执行文件是 64 位 ELF,alpine 映像是 64 位,并且可执行文件在不同的容器中工作。所以大概修剪后的高山库与我的可执行文件不兼容。这node.js Docker 中心页面笔记:
主要警告[在基于 Alpine 的容器中运行]是它确实使用穆斯勒libc代替glibc 和朋友们,因此某些软件可能会遇到问题,具体取决于其 libc 要求的深度。然而,大多数软件都没有这个问题,所以这个变体通常是一个非常安全的选择。看这个黑客新闻评论线程有关可能出现的问题的更多讨论以及使用基于 Alpine 的图像的一些赞成/反对比较。
我的解决方案是使用不同的(例如基于 Debian Jessie 的)容器映像。
答案4
对我来说,我试图在 64 位操作系统上运行 32 位应用程序,如 user1334609 提到的,所以我需要安装 32 位兼容性库。我在 Ubuntu 上,所以我这样做了:
dpkg --add-architecture i386
apt update
apt install libc6-i386
它起作用了,我的 elf 文件能够找到 ld-linux。然后它加载一些库失败,我一一排除了故障。