Perché ci sono `/ lib` e` / lib64` ma solo `/ bin`?

Nel mio laptop:

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

Esistono due diverse cartelle per le librerie x86e x86_64:

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

Perché per i binari esiste solo una directory?

PS Sono anche interessato ad Android ma spero che la risposta dovrebbe essere la stessa.

linux android architecture

— Gluttton
fonte

Solo in uno? Vedo entrambi /bine /sbinlì. Qual'è la domanda? Stai chiedendo la differenza tra /libe /lib64?

— Kusalananda

@Kusalananda, intendo dire che non esiste una cartella indipendente per x86_64(né per /binno per /sbin).

— Gluttton,

L'OP IMO vuole sapere perché non esiste /bin64.

— Arkadiusz Drabczyk,

Circa un'applicazione che beneficia di avere entrambe le versioni a 32 e 64 bit (WINE) la aggira avendo binari di nome diverso ( wine*32e wine*64).

— Ignacio Vazquez-Abrams,

@ IgnacioVazquez-Abrams: bisogna anche dire che colleghi binari a librerie, non viceversa. Quindi i binari non devono essere partizionati da 32/64 bitness.

— smci,

Innanzitutto, perché ci sono separati /libe /lib64:

Lo standard di gerarchia dei filesystem menziona la separazione /libe l' /lib64esistenza perché:

10.1. Potrebbero esserci una o più varianti della directory / lib su sistemi che supportano più di un formato binario che richiede librerie separate. (...) Questo è comunemente usato per il supporto a 64 o 32 bit su sistemi che supportano più formati binari, ma richiedono librerie con lo stesso nome. In questo caso, / lib32 e / lib64 potrebbero essere le directory della libreria e / lib un link simbolico a una di esse.

Sul mio Slackware 14.2 per esempio ci sono /libe /lib64 directory rispettivamente per le librerie a 32 e 64 bit anche se /libnon è un collegamento simbolico come lo snippet di FHS suggerirebbe:

$ 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

Ci sono due libc.so.6librerie in /libe /lib64.

Ogni binario ELF creato dinamicamente contiene un percorso hardcoded all'interprete, in questo 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]

Il compito dell'interprete è caricare le librerie condivise necessarie. Puoi chiedere a un interprete GNU quali librerie caricare senza nemmeno usare un binario LD_TRACE_LOADED_OBJECTS=1o un lddwrapper:

$ 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)

Come puoi vedere, un determinato interprete sa esattamente dove cercare le librerie: la versione a 32 bit cerca le librerie /libe la versione a 64 bit cerca le librerie /lib64.

Lo standard FHS afferma quanto segue /bin:

/ bin contiene comandi che possono essere utilizzati sia dall'amministratore di sistema che dagli utenti, ma che sono richiesti quando non sono montati altri file system (ad es. in modalità utente singolo). Può anche contenere comandi utilizzati indirettamente dagli script.

IMO il motivo per cui non ci sono distinti /bined /bin64è che se avessimo il file con lo stesso nome in entrambe queste directory non potremmo chiamarne uno indirettamente perché dovremmo inserire /bino /bin64prima $PATH.

Tuttavia, nota che quanto sopra è solo la convenzione: il kernel di Linux non importa se hai separato /bine /bin64. Se li desideri, puoi crearli e configurare il tuo sistema di conseguenza.

Hai anche menzionato Android - nota che, tranne per l'esecuzione di un kernel Linux modificato, non ha nulla a che fare con i sistemi GNU come Ubuntu - no glibc, no bash (per impostazione predefinita, puoi ovviamente compilarlo e distribuirlo manualmente) e anche la struttura delle directory è completamente diverso.

— Arkadiusz Drabczyk
fonte

I tuoi ls -lesempi non sono particolarmente germani. Ciò che sarebbe utile è l'output di ls -l /lib /lib64, che probabilmente mostra che esso /libstesso è un link simbolico.

— Chrylis

Volevi dire ls -ld, e no, /libnon è un link simbolico sul mio Slackware 14.2sistema.

— Arkadiusz Drabczyk,

Le librerie hanno diversi md5sums: dfd029d25c58831bc5db671aec99a36f /lib64/libc.so.6, 987e7b736f316cc8da87ca2f38dae93e /lib/libc.so.6.

— Arkadiusz Drabczyk,

In tal caso, la visualizzazione dei collegamenti simbolici nella directory non si collega alla citazione.

— Chrylis

LD_TRACE_LOADED_OBJECTS = 1 è obsoleto a causa di un problema di sicurezza e ldd non lo utilizza più. Motivo: ldd / path / to / malicious-static-binary è stato utilizzato per rilevare i sistemi perché gli amministratori di sistema si aspettavano che ldd guardasse solo il binario e non lo eseguisse. Inoltre, il controllo della presenza di elettricità statica o no è inadeguato poiché è possibile creare un binario per utilizzare un caricatore dannoso.

— Joshua,

Il motivo è che le directory lib / lib64 possono contenere file che hanno lo stesso nome perché sono librerie condivise con diversi programmi. Metterli in directory separate risolve il conflitto. Non c'è (di solito ...) nessuna buona ragione per distribuire gli stessi file eseguibili sullo stesso sistema che sono a 32/64 bit, ma poiché può esserci una combinazione di eseguibili, è necessario fornire le librerie condivise.

— Thomas Dickey
fonte