Primeiro, por que existem separados /lib
e /lib64
:
O padrão de hierarquia do sistema de arquivos
menciona que se separam /lib
e /lib64
existem 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 /lib
e /lib64
diretórios para bibliotecas de 32 e 64 bits, respectivamente, mesmo que
/lib
nã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.6
bibliotecas em /lib
e /lib64
.
Cada binário ELF construído dinamicamente
contém um caminho codificado para o intérprete, 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 intérprete GNU que bibliotecas ele carregaria sem nem mesmo executar um uso binário 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 - a versão de 32 bits procura por bibliotecas /lib
e 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 /bin
e /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 /bin
ou /bin64
pela 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 /bin
e /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.
/bin
e/sbin
lá. Qual é a pergunta? Você está perguntando sobre a diferença entre/lib
e/lib64
?