在支持同一个文件时找不到execve文件!

我认识的人在跑'
lmutil
'时遇到问题所以我让他们去
strace -f lmutil
。为什么
execve
失败了“没有这样的档案”!!!这是没有意义的,因为我正在stra同一个文件!到底是怎么回事?
strace -f /home/tabitha/Starprogram/FLEXlm_11.7/linux-x86_64-2.3.4/bin/lmutil
输出:
execve("/home/tabitha/Starprogram/FLEXlm_11.7/linux-x86_64-2.3.4/bin/lmutil", ["/home/tabitha/Starprogram/FLEXlm"...], [/* 38 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7cb8b0000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3)                                = 0
munmap(0x7fd7cb8b0000, 4096)            = 0
exit_group(1)                           = ?
ldd输出 $ ldd ./lmutil         linux-vdso.so.1 =>(0x00007fffcd5ff000)         libpthread.so.0 => /lib/libpthread.so.0(0x00007fe40ebbe000)         libm.so.6 => /lib/libm.so.6(0x00007fe40e93b000)         libgcc_s.so.1 => /lib/libgcc_s.so.1(0x00007fe40e724000)         libc.so.6 => /lib/libc.so.6(0x00007fe40e3a1000)         libdl.so.2 => /lib/libdl.so.2(0x00007fe40e19d000)         /lib64/ld-lsb-x86-64.so.3 => /lib64/ld-linux-x86-64.so.2(0x00007fe40edf5000) $ find。 -name lmutil -exec file {} ; ./bin.linux.x86_64/lmutil:用于GNU / Linux 2.4.0的ELF 64位LSB可执行文件,AMD x86-64,版本1(SYSV),动态链接(使用共享库),用于GNU / Linux 2.4。 0,剥离 ./bin.linux.x86/lmutil:用于GNU / Linux 2.2.5的ELF 32位LSB可执行文件,Intel 80386,版本1(SYSV),动态链接(使用共享库),用于GNU / Linux 2.2.5,剥离 ./lmutil:Bourne shell脚本文本可执行文件     
已邀请:
您尝试执行的文件(
…/lmutil
)存在,但其“加载器”不存在,其中 本机可执行文件的加载程序是其动态加载程序,例如
/lib/ld-linux.so.2
; 脚本的加载程序是其shebang行中提到的程序,例如,如果脚本以
#!/bin/sh
开头,则为
/bin/sh
。 从目录的名称来看,很有可能
lmutil
是一个amd64 Linux二进制文件,寻找
/lib64/ld-linux-x86-64.so.2
作为其加载器,但你有一个运行386(即32位)用户空间的amd64 Linux内核。您需要为您的平台获取合适的二进制文件。 我认为这种情况是Unix最误导性的错误信息。不幸的是修复它很难:内核只能向程序的调用者报告一个数字错误代码,所以它只有“找不到命令”(
ENOENT
)的空间,而不是它正在寻找的加载程序的名称。这是
strace
无效的极少数情况之一。     
你的ldd输出是指/lib64/ld-lsb-x86-64.so.3,但是这个加载器可能实际上不存在,除非(在Ubuntu上)你已经安装了lsb-core软件包。包的postinst脚本在/ lib *目录中创建相关的符号链接。     
只是一点推测,但我的第一个问题是,如果有这个问题的用户可以自己运行可执行文件而不需要strace。 execve手册页也表示如果找不到文件或必需的脚本interepreter或共享库,ENOENT将会出现。 (我注意到这里涉及64位。是否有正确的库?) 该文件是本机可执行文件还是某种类型的脚本? 这看起来像许可经理 - 任何机会让它本身有意难以调试? 说到用户,'tabitha'在可执行文件所在的目录中存在问题的用户?或者我们是否正在考虑尝试运行由另一个普通用户安装的程序而不是通过root的正常系统范围的方式可能的复杂性?     
从execve手册页:   成功时,execve()不返回,返回错误-1,并正确设置errno。
strace
假设
-1
表示“未找到文件”,因为
errno
ENOENT
-1
strace
没有区别。 从本质上讲,你可以忽略这一点:
-1
只是意味着发生了一些错误。
strace
输出不会告诉你
errno
的值是多少。 我写这个作为一个警告电话,不要用
strace
跳回到结论并返回值,即使可能会发现
errno
仍然是
ENOENT
。     
您可以使用
readelf
(任何readelf都应该这样做,您不需要来自特殊的交叉编译器工具链)来检查动态加载或可执行文件所期望的加载器。
$ readelf -l <filename> |grep -i interp
...
[Requesting program interpreter: /system/bin/linker]
    

要回复问题请先登录注册