Por que existem `/ lib` e` / lib64`, mas apenas `/ bin`?

No meu laptop:

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

Existem duas pastas diferentes para bibliotecas x86e x86_64:

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

Por que para binários existe apenas um diretório?

PS: Também estou interessado no Android, mas espero que a resposta seja a mesma.

Primeiro, por que existem separados /libe /lib64:

O padrão de hierarquia do sistema de arquivos menciona que se separam /libe /lib64existem porque:

10.1 Pode haver uma ou mais variantes do diretório / lib em sistemas que suportam mais de um formato binário que requer bibliotecas separadas. (...) Geralmente é usado para suporte de 64 ou 32 bits em sistemas que suportam vários formatos binários, mas requerem bibliotecas com o mesmo nome. Nesse caso, / lib32 e / lib64 podem ser os diretórios da biblioteca e / lib um link simbólico para um deles.

No meu Slackware 14.2, por exemplo, existem /libe /lib64 diretórios para bibliotecas de 32 e 64 bits, respectivamente, mesmo que /libnão sejam um link simbólico, como sugere o snippet do FHS:

$ 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

Existem duas libc.so.6bibliotecas em /libe /lib64.

Cada binário ELF construído dinamicamente contém um caminho codificado para o intérprete, neste caso /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]

O trabalho do intérprete é carregar as bibliotecas compartilhadas necessárias. Você pode perguntar a um intérprete GNU que bibliotecas ele carregaria sem nem mesmo executar um uso binário LD_TRACE_LOADED_OBJECTS=1ou um 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)

Como você pode ver, um determinado intérprete sabe exatamente onde procurar bibliotecas - a versão de 32 bits procura por bibliotecas /libe a versão de 64 bits procura por bibliotecas /lib64.

O padrão FHS diz o seguinte sobre /bin:

/ bin contém comandos que podem ser usados ​​pelo administrador do sistema e pelos usuários, mas que são necessários quando nenhum outro sistema de arquivos é montado (por exemplo, no modo de usuário único). Também pode conter comandos que são usados ​​indiretamente por scripts.

IMO a razão pela qual não há separada /bine /bin64é que, se tivéssemos o arquivo com o mesmo nome em ambos os diretórios que não poderia chamar um deles indiretamente, porque teríamos de colocar /binou /bin64pela primeira vez em $PATH.

No entanto, observe que o exposto acima é apenas a convenção - o kernel do Linux realmente não se importa se você tiver separado /bine /bin64. Se você os quiser, poderá criá-los e configurar seu sistema de acordo.

Você também mencionou o Android - observe que, exceto para a execução de um kernel Linux modificado, ele não tem nada a ver com sistemas GNU como o Ubuntu - no glibc, no bash (por padrão, é claro que você pode compilar e implantar manualmente) e também a estrutura de diretórios é completamente diferente.

O motivo é que os diretórios lib / lib64 podem conter arquivos com o mesmo nome, porque são bibliotecas compartilhadas com diversos programas. Colocá-los em diretórios separados resolve o conflito. Não há (normalmente ...) uma boa razão para distribuir executáveis ​​com o mesmo nome no mesmo sistema com 32/64 bits, mas como pode haver uma mistura de executáveis, as bibliotecas compartilhadas precisam ser fornecidas.