Pourquoi il y a `/ lib` et` / lib64` mais seulement `/ bin`?

Dans mon ordinateur portable:

$ cat /etc/issue  
Ubuntu 18.04 LTS \n \l

Il existe deux dossiers différents pour les bibliothèques x86et x86_64:

~$ ls -1 /  
bin
lib
lib64
sbin
...

Pourquoi pour les binaires existe un seul répertoire?

PS Je m'intéresse aussi à Android mais j'espère que la réponse devrait être la même.

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.

La raison en est que les répertoires lib / lib64 peuvent contenir des fichiers qui portent le même nom car ce sont des bibliothèques partagées avec divers programmes. Les placer dans des répertoires séparés résout le conflit. Il n'y a (généralement ...) aucune bonne raison de distribuer sur le même système des exécutables portant le même nom qui sont 32/64 bits, mais comme il peut y avoir un mélange d'exécutables, les bibliothèques partagées doivent être fournies.