Primeiro, por que há /lib e /lib64 separados:
O Padrão de hierarquia do sistema de arquivos
menciona que separam /lib e /lib64 porque:
10.1. There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries. (...) This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them.
No meu Slackware 14.2, por exemplo, há /lib e /lib64
diretórios para bibliotecas de 32 e 64 bits, respectivamente, embora
/lib não é um link simbólico que o snippet do FHS sugere:
$ 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 bibliotecas libc.so.6 em /lib e /lib64 .
Cada dinamicamente construído
Binário ELF
contém um caminho codificado para o interpretador, neste caso
/lib/ld-linux.so.2 ou /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 interpretador GNU que bibliotecas ele carregaria sem
executando um binário usando LD_TRACE_LOADED_OBJECTS=1 ou um ldd wrapper:
$ 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 - versão de 32 bits procura bibliotecas em /lib e 64 bits
versão procura bibliotecas em /lib64 .
O padrão FHS diz o seguinte sobre /bin :
/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts.
IMO a razão pela qual não há /bin e /bin64 separados é que, se tivéssemos
o arquivo com o mesmo nome em ambos os diretórios, não poderíamos chamar um deles
indiretamente porque teríamos que colocar /bin ou /bin64 primeiro
$PATH .
No entanto, observe que o acima é apenas a convenção - o Linux
O kernel realmente não se importa se você tem /bin e /bin64 separadas.
Se você quiser, você pode criá-los e configurar seu sistema de acordo.
Você também mencionou o Android - observe que, exceto para executar uma modificação Kernel Linux não tem nada a ver com os sistemas GNU como Ubuntu - sem glibc, sem bash (por padrão, você pode compilar e implantar manualmente), e também a estrutura de diretório é completamente diferente.