☰

Aktualisieren

tag-icon • tag-icon dynamic-linking ld
Aktualisieren

Ich experimentiere mit ELF- RUNPATHVariablen für dynamische Abhängigkeiten. Dabei habe ich eine Kopie der bashBinärdatei mit geänderten Werten erhalten. Wenn ich sie RUNPATHausführe, lddwird Folgendes zurückgegeben:

$ ldd ./bash 
    linux-vdso.so.1 =>  (0x00007ffe6bdf9000)
    libtinfo.so.5 (0x00007fbf8b97c000)
    libdl.so.2 (0x00007fbf8b776000)
    libc.so.6 (0x00007fbf8b3a5000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fbf8bba7000)

- warum gibt es keine Pfade zu den Abhängigkeiten (von meiner benutzerdefinierten RUNPATH) oder not foundwas bedeutet das?

Meine Vermutung wäre: lddDie Dateien können nicht gefunden werden, aber sie sind im Speicher (die Zahlen in den Klammern sind die Adressen) und ldderfährt irgendwie davon, über einen Cash-Mechanismus, ist das richtig? Aber wie kommt es dann, dass ldddie Dateien nicht gefunden werden? Wenn sie nicht abgerufen werden können RUNPATH, sollte es doch zu den Standardverzeichnissen übergehen, oder?

Aktualisieren

Heute findet er die Dateien (waren es also gestern die Cashes?):

$ cd dir_chroot2/
$ ldd ./bash
    linux-vdso.so.1 =>  (0x00007ffed3530000)
    libtinfo.so.5 => /home/.../dir_chroot2/./libtinfo.so.5 (0x00007f72c14a8000)
    libdl.so.2 => /home/.../dir_chroot2/./libdl.so.2 (0x00007f72c12a1000)
    libc.so.6 => /home/.../dir_chroot2/./libc.so.6 (0x00007f72c0ed0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f72c16d4000)

-- wird aber ld-linux-x86-64.so.2trotzdem aus dem Systemverzeichnis abgerufen, obwohl bashdie Binärdatei und alle darüber liegenden Bibliotheken vorhanden sind RUNPATH=$ORIGIN/. Warum ist das so? Ist linux-vdso.so.1es irgendwie verknüpft?

verwandte Informationen