Во-первых, почему существуют отдельные /libи /lib64:
Filesystem Hierarchy Standard
отмечает , что отдельные /libи /lib64существуют , потому что:
10.1. В системах может быть один или несколько вариантов каталога / lib, которые поддерживают более одного двоичного формата, требующего отдельных библиотек. (...) Это обычно используется для поддержки 64-битных или 32-битных систем, которые поддерживают несколько двоичных форматов, но требуют библиотек с одинаковым именем. В этом случае / lib32 и / lib64 могут быть каталогами библиотеки, а / lib - символической ссылкой на один из них.
На моем Slackware 14.2, например, есть /libи /lib64
каталоги для 32-битных и 64-битных библиотек соответственно, хотя
/libэто и не символическая ссылка, как предполагает фрагмент кода 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
Есть две libc.so.6библиотеки /libи /lib64.
Каждый динамически построена
ELF двоичный
содержит жестко запрограммированный путь к интерпретатору, в этом случае либо
/lib/ld-linux.so.2или /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]
Работа переводчика заключается в загрузке необходимых общих библиотек. Вы можете спросить интерпретатор GNU, какие библиотеки он будет загружать, даже не запуская бинарный файл LD_TRACE_LOADED_OBJECTS=1или lddоболочку:
$ 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)
Как видите, данный интерпретатор точно знает, где искать библиотеки - 32-битная версия ищет библиотеки в, /libа 64-битная версия ищет библиотеки в /lib64.
Стандарт FHS гласит следующее /bin:
/ bin содержит команды, которые могут использоваться как системным администратором, так и пользователями, но требуются, если не смонтированы другие файловые системы (например, в однопользовательском режиме) Он также может содержать команды, которые косвенно используются скриптами.
IMO причина, по которой не существует отдельных /binи /bin64состоит в том, что если бы у нас был файл с одинаковым именем в обоих этих каталогах, мы не могли бы вызвать один из них косвенно, потому что мы должны были бы поместить /binили /bin64сначала в
$PATH.
Тем не менее, обратите внимание, что вышесказанное является всего лишь соглашением - ядру Linux на самом деле все равно, если у вас есть отдельные /binи /bin64. Если вы хотите их, вы можете создать их и настроить свою систему соответственно.
Вы также упомянули Android - обратите внимание, что кроме запуска модифицированного ядра Linux, он не имеет ничего общего с системами GNU, такими как Ubuntu - без glibc, без bash (по умолчанию вы, конечно, можете скомпилировать и развернуть его вручную), а также со структурой каталогов. совершенно другой.
/binи/sbinтам, и там. В чем вопрос? Вы спрашиваете о разнице между/libи/lib64?