Erstens, warum gibt es separate /libund /lib64:
Der Dateisystem-Hierarchie-Standard
erwähnt, dass getrennt /libund /lib64vorhanden sind, weil:
10.1. Es kann eine oder mehrere Varianten des Verzeichnisses / lib auf Systemen geben, die mehr als ein Binärformat unterstützen, für das separate Bibliotheken erforderlich sind. (...) Dies wird normalerweise für die 64-Bit- oder 32-Bit-Unterstützung auf Systemen verwendet, die mehrere Binärformate unterstützen, jedoch Bibliotheken mit demselben Namen erfordern. In diesem Fall sind / lib32 und / lib64 möglicherweise die Bibliotheksverzeichnisse und / lib ein Symlink zu einem dieser Verzeichnisse.
Auf meinem Slackware 14.2 zum Beispiel gibt es /libund /lib64
Verzeichnisse für 32-Bit- und 64-Bit - Bibliotheken jeweils obwohl
/libnicht als Symlink wie die FHS würde vorschlagen Snippet:
$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11 2016 /lib/libc.so.6 -> libc-2.23.so
$ ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11 2016 /lib64/libc.so.6 -> libc-2.23.so
Es gibt zwei libc.so.6Bibliotheken in /libund /lib64.
Jede dynamisch erstellte
ELF-Binärdatei
enthält einen fest codierten Pfad zum Interpreter. In diesem Fall entweder
/lib/ld-linux.so.2oder /lib64/ld-linux-x86-64.so.2:
$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, not stripped
$ readelf -a main | grep 'Requesting program interpreter'
[Requesting program interpreter: /lib/ld-linux.so.2]
$ file ./main64
./main64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
$ readelf -a main64 | grep 'Requesting program interpreter'
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Die Aufgabe des Interpreters besteht darin, die erforderlichen gemeinsam genutzten Bibliotheken zu laden. Sie können einen GNU-Interpreter fragen, welche Bibliotheken er laden würde, ohne eine Binärdatei LD_TRACE_LOADED_OBJECTS=1oder einen lddWrapper auszuführen:
$ LD_TRACE_LOADED_OBJECTS=1 ./main
linux-gate.so.1 (0xf77a9000)
libc.so.6 => /lib/libc.so.6 (0xf760e000)
/lib/ld-linux.so.2 (0xf77aa000)
$ LD_TRACE_LOADED_OBJECTS=1 ./main64
linux-vdso.so.1 (0x00007ffd535b3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f56830b3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f568347c000)
Wie Sie sehen können, weiß ein bestimmter Interpreter genau, wo nach Bibliotheken gesucht werden muss. Die 32-Bit-Version sucht nach Bibliotheken in /libund die 64-Bit-Version sucht nach Bibliotheken in /lib64.
Der FHS-Standard sagt Folgendes aus /bin:
/ bin enthält Befehle, die sowohl vom Systemadministrator als auch von Benutzern verwendet werden können, jedoch erforderlich sind, wenn keine anderen Dateisysteme eingehängt sind (z. B. im Einzelbenutzermodus). Es kann auch Befehle enthalten, die indirekt von Skripten verwendet werden.
IMO ist der Grund , warum es nicht getrennt ist /binund /bin64dass , wenn wir die Datei mit dem gleichen Namen in beiden Verzeichnissen haben wir nicht einen von ihnen indirekt nennen könnten , weil wir setzen müssten /binoder /bin64zuerst in
$PATH.
Beachten Sie jedoch, dass dies nur die Konvention ist - dem Linux-Kernel ist es egal, ob Sie separate /binund verwenden /bin64. Wenn Sie sie möchten, können Sie sie erstellen und Ihr System entsprechend einrichten.
Sie haben auch Android erwähnt - beachten Sie, dass es außer dem Ausführen eines modifizierten Linux-Kernels nichts mit GNU-Systemen wie Ubuntu zu tun hat - kein glibc, kein bash (standardmäßig können Sie es natürlich manuell kompilieren und bereitstellen) und auch die Verzeichnisstruktur ist ganz anders.
/binund/sbindort. Was ist die Frage? Fragen Sie nach dem Unterschied zwischen/libund/lib64?