ldd Dies ist eine gute einfache Methode, um nach gemeinsam genutzten Bibliotheken zu suchen, die von einer bestimmten ausführbaren Datei verwendet werden oder werden. Es funktioniert jedoch nicht immer wie erwartet. Im folgenden Shell-Snippet sehen Sie beispielsweise, wie es "fehlschlägt", die libreadline "dependency" in der Python-Binärdatei zu finden

Ich habe viele andere Distributionen ausprobiert, aber ich kopiere aus Tikanga

<code>$ 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
</code>

Sehen Sie wasldd funktioniert standardmäßig installiertpython (aus offiziellen Repositories).

<code>$ 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 (0x00000030e0600000)
    libc.so.6 => /lib64/libc.so.6 (0x00000030e0200000)
    /lib64/ld-linux-x86-64.so.2 (0x00000030dfe00000)
$ ldd `which python` | grep readline
$
</code>

Über readline wurde nichts gefunden. Jetzt weiß ich aus der interaktiven Verwendung, dass diese Binärdatei über echte Funktionalität verfügt. Versuchen Sie also nicht, herauszufinden, woher sie stammt.

<code>$ 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
</code>

Startete eine interaktive Python-Sitzung im Hintergrund (pid 21003)

<code>$ 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   247544 6821551 /usr/lib64/libreadline.so.5.1
python  21003 ddvento  mem    REG    8,3    21808 6965997 /usr/lib64/python2.4/lib-dynload/readline.so
</code>

Bingo! Hier ist es readline!

Diese Technik funktioniert jedoch nur, wenn die Bibliothek effektiv geladen ist, sodass sie beispielsweise nicht gefunden wird/usr/lib64/libtcl8.4.so bis der python prozess sowas nicht mehr läuftfrom Tkinter import *

Ich habe also zwei Fragen:

Ich glaube das Problem mitldd ist, dass es die Verwendung des Standard-Loaders voraussetzt, wohingegen Python sehr wahrscheinlich einen eigenen speziellen Loader verwendet (damit Sie die ausführbare Datei nicht jedes Mal neu verknüpfen müssen, wenn Sie ein neues Python-Modul installieren, das kein reines Python ist, sondern einige c / c ++ / fortran code). Ist das richtig?

Wenn eine ausführbare Datei ihren eigenen Loader verwendet, gibt es keine offensichtliche Antwort auf die Frage "Wie finde ich alle möglichen Bibliotheken, die diese ausführbare Datei laden kann": Es hängt davon ab, was der Loader tut. Aber gibt es eine Möglichkeit herauszufinden, welche Bibliotheken von Python geladen werden können?

PS: bezogen auf 1. Wenn Sie auf dieser Frage landen, sollten Sie bereits Folgendes wissen, aber wenn nicht, sollten Sie: sehen, wie einfach es ist, alles durcheinander zu bringenldd Ausgabe (es ist etwas schwieriger, es nur teilweise zu vermasseln):

<code>$ 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.
</code>