ldd是检查给定可执行文件正在或将要使用的共享库的一种简单方法.但是它并不总是按预期工作.例如,请参阅以下
shell片段,演示如何“失败”将libreadline“依赖”发现到
python二进制文件中
我尝试了很多其他发行版,但我是从Tikanga复制的
$lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 5.6 (Tikanga) Release: 5.6 Codename: Tikanga
查看ldd在默认安装的python上的作用(来自官方存储库).
没有找到关于readline的内容.现在我从交互式使用中知道这个二进制文件确实具有现实功能,所以不要试图看看它来自何处.
在后台开始交互式python会话(pid 21003)
答对了！这是readline！
但是,这种技术只有在库被有效加载时才有效,所以例如它找不到/usr/lib64/libtcl8.4.so,直到python进程没有像Tkinter import *那样运行.
所以我有两个问题：
>我相信ldd的问题在于它假定使用标准加载器,而很可能python正在使用自己的特殊加载器(这样你就不必在每次安装新的python模块时重新链接可执行文件了不是纯粹的python,但有一些c / c / fortran代码).它是否正确？
>显然,如果一个可执行文件正在使用它自己的加载器,那么“如何找到这个可执行文件可能加载的所有库”的问题没有明显的答案：它取决于加载器的功能.但有没有办法找出python可以加载哪些库？PS：与1.相关如果你要登陆这个问题你应该已经知道以下内容了,但如果不这样做你应该：看看完全弄乱ldd输出是多么简单(只是部分搞乱它有点困难)：
$which python /usr/bin/python $ldd `which python` libpython2.4.so.1.0 => /usr/lib64/libpython2.4.so.1.0 (0x00000030e6200000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e0e00000) libdl.so.2 => /lib64/libdl.so.2 (0x00000030e0a00000) libutil.so.1 => /lib64/libutil.so.1 (0x00000030ee800000) libm.so.6 => /lib64/libm.so.6 (0x00000030e$lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 5.6 (Tikanga) Release: 5.6 Codename: Tikanga00)$lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 5.6 (Tikanga) Release: 5.6 Codename: Tikanga
libc.so.6 => /lib64/libc.so.6 (0x00000030e0200000)
/lib64/ld-linux-x86-64.so.2 (0x00000030dfe00000)
$ldd `which python` | grep readline
$
$python & [1] 21003 $Python 2.4.3 (#1,Dec 10 2010,17:24:35) [GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2 Type "help","copyright","credits" or "license" for more information. [1]+ Stopped python$lsof -p 21003 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME python 21003 ddvento cwd DIR 0,33 16384 164304 /glade/home/ddvento/loader-test python 21003 ddvento rtd DIR 8,3 4096 2 / python 21003 ddvento txt REG 8,3 8304 6813419 /usr/bin/python python 21003 ddvento mem REG 8,3 143600 8699326 /lib64/ld-2.5.so python 21003 ddvento mem REG 8,3 1722304 8699327 /lib64/libc-2.5.so python 21003 ddvento mem REG 8,3 615136 8699490 /lib64/libm-2.5.so python 21003 ddvento mem REG 8,3 23360 8699458 /lib64/libdl-2.5.so python 21003 ddvento mem REG 8,3 145824 8699445 /lib64/libpthread-2.5.so python 21003 ddvento mem REG 8,3 247544 6821551 /usr/lib64/libreadline.so.5.1 python 21003 ddvento mem REG 8,3 15840 8699446 /lib64/libtermcap.so.2.0.8 python 21003 ddvento mem REG 8,3 1244792 6833317 /usr/lib64/libpython2.4.so.1.0 python 21003 ddvento mem REG 8,3 18152 8699626 /lib64/libutil-2.5.so python 21003 ddvento mem REG 8,3 56446448 6832889 /usr/lib/locale/locale-archive python 21003 ddvento mem REG 8,3 21808 6965997 /usr/lib64/python2.4/lib-dynload/readline.so python 21003 ddvento mem REG 8,3 25464 6901074 /usr/lib64/gconv/gconv-modules.cache python 21003 ddvento 0u CHR 136,1 3 /dev/pts/1 python 21003 ddvento 1u CHR 136,1 3 /dev/pts/1 python 21003 ddvento 2u CHR 136,1 3 /dev/pts/1 $lsof -p 21003 | grep readline python 21003 ddvento mem REG 8,3 21808 6965997 /usr/lib64/python2.4/lib-dynload/readline.so$cat hello.c #include <stdio.h> int main() { printf("Hello world.\n"); return 0; } $gcc -static hello.c -o loader $gcc -Wl,--dynamic-linker,./loader hello.c -o hello $./hello Hello world. $ldd ./hello Hello world.
