Premièrement, pourquoi il y a séparé /libet /lib64:
La norme de hiérarchie du système de fichiers
mentionne que se séparent /libet /lib64existent parce que:
10.1. Il peut y avoir une ou plusieurs variantes du répertoire / lib sur les systèmes qui prennent en charge plusieurs formats binaires nécessitant des bibliothèques distinctes. (...) Ceci est couramment utilisé pour la prise en charge 64 bits ou 32 bits sur les systèmes qui prennent en charge plusieurs formats binaires, mais nécessitent des bibliothèques du même nom. Dans ce cas, / lib32 et / lib64 peuvent être les répertoires de bibliothèque et / lib un lien symbolique vers l'un d'entre eux.
Sur mon Slackware 14.2 par exemple , il y a /libet /lib64
répertoires pour respectivement , même si 32 bits et bibliothèques 64 bits
/libne sont pas aussi un lien symbolique comme snippet FHS suggère:
$ 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
Il y a deux libc.so.6bibliothèques dans /libet /lib64.
Chaque dynamiquement construit
binaire ELF
contient un chemin codé en dur pour l'interprète, soit dans ce cas
/lib/ld-linux.so.2ou /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]
Le travail de l'interpréteur est de charger les bibliothèques partagées nécessaires. Vous pouvez demander à un interpréteur GNU quelles bibliothèques il chargerait sans même exécuter un binaire en utilisant LD_TRACE_LOADED_OBJECTS=1ou un lddwrapper:
$ 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)
Comme vous pouvez le voir, un interprète donné sait exactement où chercher les bibliothèques - la version 32 bits recherche les bibliothèques dans /libet la version 64 bits recherche les bibliothèques dans /lib64.
La norme FHS dit ce qui suit sur /bin:
/ bin contient des commandes qui peuvent être utilisées à la fois par l'administrateur système et par les utilisateurs, mais qui sont requises lorsqu'aucun autre système de fichiers n'est monté (par exemple en mode mono-utilisateur). Il peut également contenir des commandes qui sont utilisées indirectement par des scripts.
OMI, la raison pour laquelle il n'y a pas de fichier séparé /binet /bin64c'est que si nous avions le fichier avec le même nom dans ces deux répertoires, nous ne pourrions pas appeler l'un d'eux indirectement car nous devions le mettre /binou le /bin64commencer
$PATH.
Cependant, notez que ce qui précède n'est que la convention - le noyau Linux ne se soucie pas vraiment si vous avez séparé /binet /bin64. Si vous le souhaitez, vous pouvez les créer et configurer votre système en conséquence.
Vous avez également mentionné Android - notez que, à l'exception de l'exécution d'un noyau Linux modifié, cela n'a rien à voir avec les systèmes GNU tels que Ubuntu - pas de glibc, pas de bash (par défaut, vous pouvez bien sûr le compiler et le déployer manuellement), ainsi que la structure du répertoire est complètement différent.
/binet/sbinlà. Quelle est la question? Vous demandez la différence entre/libet/lib64?