Qual è l'opzione "soname" per la creazione di librerie condivise?

Question

Ho appreso lo "Program Library HOWTO". Ricorda che usando soname per gestire la versione come segue.

gcc -shared -fPIC -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0.0 foo.c 
ln -s libfoo.so.1.0.0 libfoo.so.1 
ln -s libfoo.so.1 libfoo.so 

E ottengo l'informazione che se il soname non è impostato. sarà uguale a libfoo.so.1.0.0, vedere la risposta da here.

E trovo che può anche funzionare senza soname, come seguire

gcc -shared -fPIC -o libfoo.so.1.0.0 foo.c 
ln -s libfoo.so.1.0.0 libfoo.so.1 
ln -s libfoo.so.1 libfoo.so 

Quindi penso che l'unico punto utile è che l'opzione soname può dire la versione della libreria condivisa quando si utilizza readelf -d libfoo.so comando per controllarlo.

Cos'altro può fare?

Answer 1

soname viene utilizzato per indicare quale compatibilità di API binarie supporta la libreria.

SONAME viene utilizzato in fase di compilazione dal linker per determinare dal file della libreria quale versione della libreria di destinazione effettiva. gcc -l NAME cercherà per lib NAME .so collegamento o file quindi catturare il suo SONAME che sarà certamente più specifico (ex libnuke.so link a libnuke.so.0.1.4 che contiene SONAME libnuke.so.0).

In fase di esecuzione il collegamento con questo viene quindi impostato nella sezione dinamica ELF NEEDED, quindi deve esistere una libreria con questo nome (o un collegamento ad essa). In fase di esecuzione SONAME viene ignorato, quindi è sufficiente il collegamento o l'esistenza del file.

Nota: SONAME viene applicato solo al collegamento/tempo di creazione e non in fase di esecuzione.

'SONAME' della libreria può essere visto con 'objdump -p file | grep SONAME'. 'NEEDED' dei binari può essere visto con 'objdump -p file | grep NEEDED'.

[EDIT] AVVERTENZA Di seguito è riportato un commento generale, non quello distribuito in linux. Vedi alla fine.

Supponiamo di avere una biblioteca con nome libnuke.so.1.2 e si sviluppa una nuova libreria libnuke:

• se la nuova libreria è una correzione dal precedente senza cambiare api, si dovrebbe tenere nello stesso soname , aumenta la versione del nome file. cioè il file sarà libnuke.so.1.2.1 ma il soname sarà ancora libnuke.so.1.2.
• se si dispone di una nuova libreria che ha solo aggiunto una nuova funzione ma non ha interrotto la funzionalità ed è ancora compatibile con la precedente si desidera utilizzare lo stesso soname del precedente più un nuovo suffisso come .1. cioè file e soname saranno libnuke.so.1.2.1. Qualsiasi programma collegato con libnuke.1.2 continuerà a funzionare con quello. I nuovi programmi collegati con libnuke.1.2.1 funzioneranno solo con quello (fino a quando la nuova subversione non sarà come libnuke.1.2.1.1).
• se la nuova libreria non è compatibile con qualsiasi libnuke: libnuke.so.2
• se la nuova libreria è compatibile con la versione precedente nuda: libnuke.so.1.3 [cioè ancora compatibile con libnuke.so.1]

[EDIT] per completare: caso di Linux.

In Linux Soname vita reale come una forma specifica. lib [NAME] [API-VERSION] .quindi [versione principale] versione principale è solo un valore intero che aumenta ad ogni cambiamento importante biblioteca. API-VERSION è vuota di default

ex libnuke.so.0

Poi vero nome del file includono le versioni minori e sovversioni es: libnuke.so.0.1.5

penso che non fornire un soname è una cattiva pratica dal momento che la rinomina del file cambierà il suo comportamento.

Answer 2

altro aspetto: Almeno su Linux voce soname fornisce un suggerimento per il sistema di runtime-linker su come creare collegamenti appropriati in/lib,/lib64 ecc eseguire il comando ldconfig tenta di creare un collegamento simbolico chiamato con SONAME, anch'esso contenuto nella cache del linker di runtime. La più recente delle librerie che taggano lo stesso SONAME vince la gara di link. Se alcuni software si basano sullo specifico SONAME e si desidera rinnovare una libreria, è necessario fornire questo SONAME per ottenere ldconfig stick su questa nuova libreria (se ldconfig viene utilizzato per ricostruire la cache e i collegamenti). Per esempio. libssl.so.6 e libcrypto.so.6 sono tali casi.

Answer 3

Supponiamo che libA.so dipenda da libB.so e che siano tutti in una directory (ovviamente la directory non può essere trovata dal linker dinamico). Se non avete impostato soname poi dlopen non funziona:

auto pB = dlopen("./libB.so", RTLD_LAZY | RTLD_GLOBAL); 
auto pA = dlopen("./libA.so", RTLD_LAZY | RTLD_GLOBAL); 

Perché runtime linker non riesce a trovare libB.so, così pA è impostato su NULL.

In questo caso soname vi salverà dall'inferno ...