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.
/biny/sbinallí. ¿Cuál es la pregunta? ¿Estás preguntando sobre la diferencia entre/liby/lib64?