Primero, por qué hay /lib separados y /lib64 :
Las menciones estándar de la jerarquía del sistema de archivos que separan /lib y /lib64 existe porque:
10.1. Puede haber una o más variantes del directorio /lib en sistemas que admitan más de un formato binario que requiera bibliotecas separadas. (...) Esto se usa comúnmente para soporte de 64 bits o 32 bits en sistemas que admiten múltiples formatos binarios, pero requieren bibliotecas con el mismo nombre. En este caso, /lib32 y /lib64 podrían ser los directorios de la biblioteca y /lib un enlace simbólico a uno de ellos.
En mi Slackware 14.2, por ejemplo, hay /lib y /lib64 directorios para bibliotecas de 32 y 64 bits respectivamente aunque /lib no es un enlace simbólico como sugeriría el fragmento de 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
Hay dos libc.so.6 bibliotecas en /lib y /lib64 .
Cada binario ELF creado dinámicamente contiene una ruta codificada al intérprete, en este caso, /lib/ld-linux.so.2 o /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=1 o un ldd envoltorio:
$ 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 dado sabe exactamente dónde buscar bibliotecas:la versión de 32 bits busca bibliotecas en /lib y la versión de 64 bits busca bibliotecas en /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 hay otros sistemas de archivos montados (por ejemplo, en modo de usuario único). También puede contener comandos que son utilizados indirectamente por scripts.
En mi opinión, la razón por la que no hay /bin separados y /bin64 es que si tuviéramos el archivo con el mismo nombre en ambos directorios, no podríamos llamar a uno de ellos directamente porque tendríamos que poner /bin o /bin64 primero 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 /bin separados y /bin64 .Si los desea, puede crearlos y configurar su sistema en consecuencia.
También mencionó Android:tenga en cuenta que, excepto por ejecutar un kernel de Linux modificado, no tiene nada que ver con los sistemas GNU como Ubuntu:sin glibc, sin bash (por defecto, puede compilarlo e implementarlo manualmente), y también la estructura del directorio es completamente diferente .
La razón es que los directorios lib/lib64 pueden contener archivos que tienen el mismo nombre porque esas son bibliotecas compartidas con diversos programas. Ponerlos en directorios separados resuelve el conflicto. No hay (generalmente...) ninguna buena razón para distribuir ejecutables del 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.