Za prvé, proč existují samostatné /lib a /lib64 :
Standardy hierarchie souborového systému, které oddělují /lib a /lib64 existují, protože:
10.1. V systémech, které podporují více než jeden binární formát vyžadující samostatné knihovny, může existovat jedna nebo více variant adresáře /lib. (...) Toto se běžně používá pro 64bitovou nebo 32bitovou podporu na systémech, které podporují více binárních formátů, ale vyžadují knihovny stejného jména. V tomto případě mohou být adresáře knihoven /lib32 a /lib64 a /lib symbolický odkaz na jeden z nich.
Na mém Slackware 14.2 je například /lib a /lib64 adresáře pro 32bitové a 64bitové knihovny, i když/lib není tak symbolický odkaz, jak by naznačoval úryvek 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
Existují dva libc.so.6 knihovny v /lib a /lib64 .
Každý dynamicky sestavený binární soubor ELF obsahuje pevně zakódovanou cestu k interpretu, v tomto případě buď/lib/ld-linux.so.2 nebo /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]
Úkolem tlumočníka je načíst potřebné sdílené knihovny. Můžete se zeptat interpreta GNU, jaké knihovny by načetl, aniž by dokonce spouštěl binární soubor pomocí LD_TRACE_LOADED_OBJECTS=1 nebo ldd obal:
$ 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)
Jak vidíte, daný interpret přesně ví, kde má knihovny hledat – 32bitová verze hledá knihovny v /lib a 64bitová verze hledá knihovny v /lib64 .
Standard FHS říká o /bin následující :
/bin obsahuje příkazy, které může používat jak správce systému, tak uživatelé, ale které jsou vyžadovány, když nejsou připojeny žádné jiné souborové systémy (např. v režimu jednoho uživatele). Může také obsahovat příkazy, které jsou nepřímo používány skripty.
IMO důvod, proč neexistují žádné samostatné /bin a /bin64 je, že pokud bychom měli soubor se stejným názvem v obou těchto adresářích, nemohli bychom volat jeden z nich přímo, protože bychom museli zadat /bin nebo /bin64 první v$PATH .
Všimněte si však, že výše uvedené je pouze konvence – linuxovému jádru je vlastně jedno, jestli máte samostatné /bin a /bin64 .Pokud je chcete, můžete je vytvořit a podle toho nastavit svůj systém.
Zmínil jste také Android - všimněte si, že kromě běhu upraveného linuxového jádra nemá nic společného s GNU systémy, jako je Ubuntu - žádné glibc, žádný bash (ve výchozím nastavení jej můžete samozřejmě zkompilovat a nasadit ručně) a také struktura adresářů je zcela odlišná .
Důvodem je, že adresáře lib/lib64 mohou obsahovat soubory, které mají náhodou stejné jméno protože to jsou knihovny sdílené s různými programy. Jejich umístěním do samostatných adresářů se konflikt vyřeší. Neexistuje (obvykle...) žádný dobrý důvod pro distribuci stejnojmenných spustitelných souborů na stejném systému, které jsou 32/64bitové, ale protože může existovat směs spustitelných souborů, je třeba zajistit sdílené knihovny.