che cosa sono * .so. *. * librerie

Question

Quando faccio ls -l in /usr/lib Vedo un sacco di librerie con estensione "sameName.so.*.*".

1. Qual è il significato di queste estensioni?
2. Perché sono creati softlink? Quali sono le loro utilizzo?

Un esempio aiuterà molto nella comprensione.

Answer 1

Questo è un trucco usato per i file oggetto versione condivisa. E 'un modo per evitare l'inferno DLL temuto che avvenne a causa di collegamento pigro.

Il vantaggio di collegamento pigro (o in ritardo vincolante) è che i componenti del vostro eseguibile possono essere modificate senza in realtà re il collegamento di tali eseguibili. Questo permette di correzioni di bug nei componenti di terze parti, senza dover spedire un nuovo eseguibile, tra le altre cose.

Lo svantaggio è esattamente lo stesso del vantaggio. Il tuo eseguibile può trovare che le ipotesi formulate circa le librerie sottostanti sono state cambiate e questo è probabile che a causare ogni tipo di problema.

delle versioni degli oggetti condivisi è un modo per evitare questo. Un'altra potrebbe essere quella non quota di oggetti a tutti, ma che ha anche pro e contro, che non voglio entrare in qui.

A titolo di esempio, diciamo che avete la versione 1 di xyz.so. Si dispone di un file e un link simbolico al file:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

Ora, quando si crea un file eseguibile exe1, che lo collega con xyz.so, seguirà il link simbolico in modo che esso memorizza xyz.so.1 nel file eseguibile come la cosa di cui ha bisogno per il carico in fase di esecuzione.

In questo modo, quando si aggiorna la libreria condivisa in tal modo:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1
-rw-r--r--  1 pax paxgroup    67890 Nov 18  2009 xyz.so.2
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.2

tuo exe1 eseguibile originale sarà ancora Carica la versione 1 dell'oggetto condiviso.

Tuttavia, tutti gli eseguibili si crea la società (come ad esempio exe2) sarà collegata con la versione 2 dell'oggetto condiviso.

---

I dettagli di implementazione effettivi possono variare un po '(sto basando la mia risposta su UNIX e Linux precedenti sembra di fare delle versioni un po' più intelligente di un semplice seguente link simbolici). IBM developerWorks ha un bel articolo su come è fatto qui .

Quando si crea un oggetto condiviso, si dà sia un nome reale e una soname. Questi vengono utilizzati per installare l'oggetto condiviso (che crea sia l'oggetto e un link ad esso).

Così si può finire con la situazione:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so.1 -> xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

con xyz.so.1.5 possedere la SONAME di xyz.so.1.

Quando i collegamenti linker in xyz.so, segue i collegamenti fino a xyz.so.1.5 e usa la sua SONAME di xyz.so.1 da memorizzare nel file eseguibile. Poi, quando si run l'eseguibile, si cerca di caricare xyz.so.1 che puntare ad una specifica xyz.so.1.N (non necessariamente la versione 1.5).

Quindi, è possibile installare xyz.so.1.6 e aggiornare il link xyz.so.1 a punto ad esso, invece, e gli eseguibili già collegate userebbero che, invece.

Un vantaggio di questo metodo di multistrato è che si può avere più librerie potenzialmente incompatibili con lo stesso nome (xyz.so.1.*, xyz.so.2.*) ma, all'interno di ogni versione principale, si può liberamente li l'aggiornamento in quanto si suppone che essere compatibile .

Quando si collega nuovi eseguibili:

• Coloro che collega con xyz.so otterrà l'ultima versione minore della più recente versione principale.
• Altro che collegano con xyz.so.1 otterrà l'ultima versione minore di una specifica versione principale.
• Altri ancora che collegano con xyz.so.1.2 otterrà una versione specifica minore di una versione specifica importante.

Answer 2

E 'un sistema di delle versioni per le librerie condivise . Ogni biblioteca dovrebbe avere 3 nomi:

1. Nome reale: il nome della libreria reale, libfoo.so.1.2.3
2. "soname": il nome registrato nel file eseguibile, e gli sguardi nome dinamica linker per, libfoo.so.1.2. Questo nome è in realtà scritto all'interno della biblioteca binario stesso, e verrà registrato nel file eseguibile in fase di collegamento. Di solito è un link simbolico a vero nome della libreria (di solito la versione più recente).
3. nome Linker: il nome assegnato al linker quando si costruisce il vostro programma. Di solito collega l'ultimo soname.

Esempio

Diciamo che avete libfoo versione 1 installato: libfoo.so -> libfoo.so.1.0 -> libfoo.so.1.0.0. Costruire la vostra bar programma con -lfoo. ora si collega a libfoo e caricherà libfoo.so.1.0 in fase di esecuzione a causa di soname. Poi si passa a una libfoo.so.1.0.1 rattoppato ma compatibile binario sostituendo vero e proprio binario. bar ancora collegamenti a libfoo.so.1.0 e non ha bisogno di essere ricostruito.

Ora immaginate si vuole costruire un nuovo baz programma che sfrutta cambiamenti incompatibili in libfoo v1.1. Si installa la nuova versione e il sistema ora hanno due versioni installate in parallelo:

1. libfoo.so.1.0 -> libfoo.so.1.0.1
2. libfoo.so -> libfoo.so.1.1 -> libfoo.so.1.1.0

nome Nota linker è stato aggiornato alla versione più recente (questa è la versione corrispondente alle intestazioni installati in /usr/include).

Si costruisce baz, e si collega a libfoo.so e carichi libfoo.so.1.1 in fase di esecuzione. Non che bar corre ancora contro libfoo.so.1.0 e non ha bisogno di essere aggiornato.