Ele*_*her 77 executable linker dynamic-linking ld
我目前在 debian (wheezy/amd64) 上有一个奇怪的问题。
我创建了一个 chroot 来安装服务器(抱歉,我无法提供更多详细信息)。让我们称其为 path /chr_path/
。为方便起见,我使用 debootstrap(也是 wheezy/amd64)初始化了这个 chroot。
在 chroot 中一切似乎都运行良好,但是当我启动服务器的安装程序脚本时,我得到了 :(
zsh: Not found /some_path/perl
由于某些原因,安装程序包含一个 perl 二进制文件)
当然,我检查了/some_path/
位置并找到了“perl”二进制文件。file
在 chroot 环境中返回:
/some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
Run Code Online (Sandbox Code Playgroud)
该文件存在,似乎没问题,具有正确的权限。我可以在它上面使用file
, ls
,vim
但是一旦我尝试执行它 -./perl
例如 - 我得到 : zsh: Not found ./perl
。
这种情况对我来说是可以理解的。而且 :
/chr_path/some_path/perl
)执行二进制文件时,它可以工作。ls
. 我检查了访问权限是否相同,但这并没有改变任何东西(一个有效,另一个无效)Gil*_*il' 80
当您无法执行依赖于“加载器”的文件时,您得到的错误可能是指加载器而不是您正在执行的文件。
/lib/ld.so
or /lib/ld-linux.so.2
,应该是一个可执行文件。/bin/sh
对于以 开头的脚本#!/bin/sh
。(在这种情况下,Bash 和 zsh 给出消息“bad interpreter”而不是“command not found”。)错误消息在没有表明加载程序是问题方面具有误导性。不幸的是,修复这个问题会很困难,因为内核接口只有报告数字错误代码的空间,而不是也表明错误实际上涉及不同的文件。一些 shell 自己为脚本完成工作(读取脚本上的#!
行并重新计算错误条件),但我见过没有尝试对本机二进制文件执行相同的操作。
ldd
也不会在二进制文件上工作,因为它通过设置一些特殊的环境变量然后运行程序来工作,让加载程序完成工作。strace
也不会提供任何有意义的信息,因为它不会报告比内核报告的更多的信息,而且正如我们所见,内核无法报告它所知道的一切。
当您尝试为正确的系统(或系统系列)和超级体系结构但错误的子体系结构运行二进制文件时,通常会出现这种情况。在这里,您在需要 ELF 二进制文件的系统上有 ELF 二进制文件,因此内核加载它们就好了。它们是在 x86_64 处理器上运行的 i386 二进制文件,因此这些指令是有意义的,并使程序能够找到它的加载程序。但该程序是一个 32 位程序(如file
输出所示),寻找 32 位 loader /lib/ld-linux.so.2
,并且您可能只/lib64/ld-linux-x86-64.so.2
在 chroot 中安装了 64 位 loader 。
您需要在 chroot 中安装 32 位运行时系统:加载程序,以及程序需要的所有库。从 Debian wheezy 开始,如果您同时需要 i386 和 x86_64 支持,请从 amd64 安装开始并激活多架构支持:运行dpkg --add-architecture i386
then apt-get update
and apt-get install libc6:i386 zlib1g:i386 …
(如果您想生成 Debian 的 perl 包的依赖项列表,以查看哪些库可能会需要,您可以使用aptitude search -F %p '~Rdepends:^perl$ ~ri386'
)。您可以通过安装ia32-libs
包来获取公共库的集合(您需要先启用多架构支持)。在 Debian amd64 到 wheezy 上,32 位加载程序在libc6-i386
包中。您可以通过安装ia32-libs
.
ldd(1)
在你的perl
二进制文件上运行。通常,Not found
文件上看似令人困惑的错误显然是因为未找到程序使用的共享库之一。
因此,对于二进制文件所需的共享库,您的 chroot 可能不完整。
归档时间: |
|
查看次数: |
57325 次 |
最近记录: |