如何查找未满足哪个ELF依赖关系? [英] How can I find which ELF dependency is not fulfilled?

问题描述

我已经使用LSB SDK构建了一个测试ELF程序(请注意，我的问题并非特定于LSB ):

I've built a test ELF program using the LSB SDK (note that my question is not specific to LSB):

$ /opt/lsb/bin/lsbcc tst.c
$ ls -l a.out 
-rwxr-xr-x 1 math math 10791 2009-10-13 20:13 a.out
$ file a.out 
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

但是我无法启动它(是的，我向您保证文件是在目录中……):

But I am unable to launch it (yes, I assure you the file is in the directory...):

$ ./a.out 
bash: ./a.out: No such file or directory

$ uname -a
Linux math 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux

我认为有一个ELF依赖关系不能满足，但我不知道如何找到它.对于库，是否有类似于ldd的工具可用于找到丢失的链接?

I think there is an ELF dependency which is not fulfill but I don't know how to find it. Is there a tool similar to ldd for libraries which can be used to found the missing link?

我认为这与2.6.15/2.6.28-15的差异无关，因为LSB编译器正在工作:

I don't think it is related to the 2.6.15/2.6.28-15 difference because the LSB compiler is working:

$ file /opt/lsb/bin/lsbcc 
/opt/lsb/bin/lsbcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped

以防万一，这是a.out的ELF动态部分:

Just in case, here is the ELF dynamic section of a.out:

 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x400428
 0x000000000000000d (FINI)               0x400638
 0x0000000000000004 (HASH)               0x400278
 0x0000000000000005 (STRTAB)             0x400350
 0x0000000000000006 (SYMTAB)             0x4002a8
 0x000000000000000a (STRSZ)              121 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x600fe8
 0x0000000000000002 (PLTRELSZ)           24 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x400410
 0x0000000000000007 (RELA)               0x4003f8
 0x0000000000000008 (RELASZ)             24 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x4003d8
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x4003ca
 0x0000000000000000 (NULL)               0x0

推荐答案

这看起来像缺少ELF解释器时会发生什么.

This looks like what happens when the ELF interpreter is missing.

确保存在/lib/ld-lsb.so.2(或类似内容；因LSB版本和体系结构而异). ldd和readelf -l将能够显示您的可执行文件正在请求的ELF解释器.

Ensure that /lib/ld-lsb.so.2 (or similar; varies by LSB version and architecture) exists. ldd and readelf -l will be able to show the ELF interpreter your executable is requesting.

(lsbcc(或LSB工具链中的某些内容)可能会通过将-Wl,--dynamic-linker=/lib/ld-lsb.so.2传递给编译器，从而覆盖系统的默认/lib/ld-linux.so.2，出于我认为很愚蠢的原因(Glibc始终提供了相当出色的向后兼容性在这里)，但在那里.)

(lsbcc (or something in the LSB toolchain) overrides the system's default /lib/ld-linux.so.2, probably by passing -Wl,--dynamic-linker=/lib/ld-lsb.so.2 to the compiler, for reasons I think are rather silly (Glibc has always provided fairly excellent backwards-compatibility here), but there you have it.)

这篇关于如何查找未满足哪个ELF依赖关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！