
No meu laptop:
$ cat /etc/issue
Ubuntu 18.04 LTS \n \l
Existem duas pastas diferentes para bibliotecas x86
e 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.
Responder1
Primeiro, por que existem separados /lib
e /lib64
:
OPadrã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. (...) Isso é comumente usado para suporte de 64 ou 32 bits em sistemas que suportam vários formatos binários, mas requerem bibliotecas com o mesmo nome. Neste 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 diretórios /lib
e /lib64
para bibliotecas de 32 e 64 bits, respectivamente, embora
/lib
não seja um link simbólico como o trecho FHS sugeriria:
$ 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 um construído dinamicamente
binário ELF
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]
A tarefa do intérprete é carregar as bibliotecas compartilhadas necessárias. Você pode perguntar a um intérprete GNU quais bibliotecas ele carregaria sem sequer executar 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 - a versão de 32 bits procura bibliotecas /lib
e a versão de 64 bits procura bibliotecas em /lib64
.
A norma FHS diz o seguinte sobre /bin
:
/bin contém comandos que podem ser usados tanto pelo administrador do sistema quanto pelos usuários, mas que são necessários quando nenhum outro sistema de arquivos está montado (por exemplo, no modo de usuário único). Também pode conter comandos que são usados indiretamente por scripts.
Na IMO, a razão pela qual não há separado /bin
é /bin64
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
or /bin64
primeiro em
$PATH
.
No entanto, observe que o que foi dito acima é apenas uma convenção - o kernel do Linux realmente não se importa se você possui /bin
arquivos /bin64
. Se desejar, você pode criá-los e configurar seu sistema de acordo.
Você também mencionou o Android - observe que, exceto pela execução de um kernel Linux modificado, ele não tem nada a ver com sistemas GNU como o Ubuntu - sem glibc, sem bash (por padrão, é claro, você pode compilá-lo e implantá-lo manualmente) e também estrutura de diretórios é completamente diferente.
Responder2
A razão é que os diretórios lib/lib64 podem conter arquivos que possuem o mesmonomeporque são bibliotecas compartilhadas com diversos programas. Colocá-los em diretórios separados resolve o conflito. Não há (geralmente...) nenhuma boa razão para distribuir executáveis com o mesmo nome no mesmo sistema de 32/64 bits, mas como pode haver uma mistura de executáveis, as bibliotecas compartilhadas devem ser fornecidas.