如何找到哪个 ELF 依赖项未满足？
我已经使用 LSB SDK 构建了一个测试 ELF 程序（请注意，我的问题并非特定于 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
但我无法启动它（是的，我向您保证文件 < strong>is 在目录中...)：
$ ./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 的库工具可以用来查找丢失的链接？
我不认为它与 2.6.15/2.6.28-15 差异有关，因为 LSB 编译器正在工作：
$ 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 动态部分：
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
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
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?
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
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这看起来就像 ELF 解释器丢失时发生的情况。
确保
/lib/ld-lsb.so.2（或类似文件；因 LSB 版本和体系结构而异）存在。ldd和readelf -l将能够显示您的可执行文件正在请求的 ELF 解释器。（
lsbcc（或 LSB 工具链中的某些内容）可能会通过传递-Wl 来覆盖系统默认的到编译器，我认为原因相当愚蠢（Glibc 总是在这里提供相当出色的向后兼容性），但你已经有了。）/lib/ld-linux.so.2，-- dynamic-linker=/lib/ld-lsb.so.2This looks like what happens when the ELF interpreter is missing.
Ensure that
/lib/ld-lsb.so.2(or similar; varies by LSB version and architecture) exists.lddandreadelf -lwill be able to show the ELF interpreter your executable is requesting.(
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.2to the compiler, for reasons I think are rather silly (Glibc has always provided fairly excellent backwards-compatibility here), but there you have it.)