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

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.

Responder1

Primeiro, por que existem separados /libe /lib64:

OPadrã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. (...) 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 /libe /lib64 para bibliotecas de 32 e 64 bits, respectivamente, embora /libnã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.6bibliotecas em /libe /lib64.

Cada um construído dinamicamente binário ELF 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]

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=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 bibliotecas /libe 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é /bin64que 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 /binor /bin64primeiro 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 /binarquivos /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.

informação relacionada