¿Por qué hay `/ lib` y` / lib64` pero solo `/ bin`?

En mi laptop

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

Hay dos carpetas diferentes para bibliotecas x86y x86_64:

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

¿Por qué para binarios existe un solo directorio?

PD: También estoy interesado en Android, pero espero que la respuesta sea la misma.

Primero, por qué hay por separado /liby /lib64:

El estándar de jerarquía del sistema de archivos menciona que se separan /liby /lib64existen porque:

10.1 Puede haber una o más variantes del directorio / lib en sistemas que admiten más de un formato binario que requiere bibliotecas separadas. (...) Esto se usa comúnmente para la compatibilidad de 64 bits o 32 bits en sistemas que admiten múltiples formatos binarios, pero requieren bibliotecas del mismo nombre. En este caso, / lib32 y / lib64 pueden ser los directorios de la biblioteca, y / lib un enlace simbólico a uno de ellos.

En mi Slackware 14.2, por ejemplo, existen /liby /lib64 directorios de bibliotecas de 32 bits y 64 bits, respectivamente, a pesar de que /libno es como un enlace simbólico como los FHS snippet sugeriría:

$ 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

Hay dos libc.so.6bibliotecas en /liby /lib64.

Cada binario ELF construido dinámicamente contiene una ruta codificada al intérprete, en este caso, /lib/ld-linux.so.2o /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]

El trabajo del intérprete es cargar las bibliotecas compartidas necesarias. Puede preguntarle a un intérprete de GNU qué bibliotecas cargaría sin siquiera ejecutar un binario usando LD_TRACE_LOADED_OBJECTS=1o un lddcontenedor:

$ 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 puede ver, un intérprete determinado sabe exactamente dónde buscar bibliotecas: la versión de 32 bits busca bibliotecas /liby la versión de 64 bits busca bibliotecas /lib64.

El estándar FHS dice lo siguiente sobre /bin:

/ bin contiene comandos que pueden ser utilizados tanto por el administrador del sistema como por los usuarios, pero que son necesarios cuando no se montan otros sistemas de archivos (por ejemplo, en modo de usuario único). También puede contener comandos que los scripts usan indirectamente.

OMI la razón por la cual no existen por separado /biny /bin64es que si tuviéramos el archivo con el mismo nombre en ambos directorios que no podíamos llamar a uno de ellos indirectamente, porque tendríamos que poner /bino /bin64por primera vez en $PATH.

Sin embargo, tenga en cuenta que lo anterior es solo la convención: al kernel de Linux realmente no le importa si tiene separado /biny /bin64. Si los desea, puede crearlos y configurar su sistema en consecuencia.

También mencionó Android: tenga en cuenta que, excepto para ejecutar un kernel de Linux modificado, no tiene nada que ver con sistemas GNU como Ubuntu: sin glibc, sin bash (de forma predeterminada, por supuesto, puede compilarlo e implementarlo manualmente), y también la estructura de directorios Es completamente diferente.

La razón es que los directorios lib / lib64 pueden contener archivos que tienen el mismo nombre porque son bibliotecas compartidas con diversos programas. Ponerlos en directorios separados resuelve el conflicto. No hay (por lo general ...) una buena razón para distribuir ejecutables con el mismo nombre en el mismo sistema que son de 32/64 bits, pero dado que puede haber una mezcla de ejecutables, se deben proporcionar las bibliotecas compartidas.