Co je soubor .so.2?

Obvykle, když vytváříte sdílené objekty (.so), pak se také staráte o verze přidáním přípon, jako je mylib.so.2.3.1. Abyste se ujistili, že vaše programy mohou načíst tuto knihovnu nebo jiné novější verze, vytvořte odkazy s názvy

mylib.so -> mylib.so.2.3.1
mylib.so.2 -> mylib.so.2.3.1
mylib.so.2.3 -> mylib.so.2.3.1

Takže vše za .so představuje version.sub-version.build (nebo podobný) Také je možné, aby s tímto schématem koexistovala více než jedna verze stejné knihovny a vše, co je nutné k přepnutí programů na použití konkrétního verze je mít na svém místě příslušné odkazy.

Dynamicky propojený binární soubor ELF (ať už jiná knihovna nebo spustitelný soubor) používá název sdíleného objektu nebo soname k identifikaci knihovny, se kterou by měl být spustitelný soubor při spuštění propojen.

Když je knihovna vytvořena jako sdílená knihovna ELF, editor odkazů v době kompilace vloží pole DT_SONAME do spustitelného souboru, jehož SONAME knihovny, do samotné knihovny. DT_SONAME je definováno ve standardu ELF jako:

Tento prvek uchovává offset tabulky řetězců řetězce zakončeného nulou, který udává název sdíleného objektu. Offset je index do tabulky zaznamenaný v DT_STRTAB vstup. Další informace o těchto názvech naleznete níže v části ‘‘Shared ObjectDependencies’’.

Takže když je nyní vytvořen spustitelný soubor, SONAME je do něj vložen. Když je spustitelný soubor spuštěn, používá linker k vyhledání knihovny v souborech v předdefinovaných umístěních pro dynamickou knihovnu. Předdefinované umístění v systému Windows by bylo všude tam, kde jsou umístěny knihovny DLL. V systémech Linux a Mac OS X a dalších systémech kompatibilních se systémem V by byly /lib a /usr/lib a případně další spoty, to závisí na použitém linkeru a může být definováno ve vlastních konfiguracích linkerů.

Ve všech případech se linker podívá, zda je knihovna pojmenovaná v záznamu soname přítomna v některém z těchto umístění, pokud ano, použije ji.

Všimněte si, že standard říká, že soname je STRING a konvence verzování se poté staly defacto standardem a zní asi takto:

Nastavte soname na libmyname.so.A a nastavte název souboru knihovny na libmyname.so.A.B nebo libmyname.so.A.B.C (v MacOSX je to libmyname.A.B.dylib). Vytvořte měkký odkaz z libmyname.so.A.B[.C]? až libmyname.so.A .

A je zachováno stejné, zatímco ABI knihovny zůstává stejné.

B (nebo B.C ) se stává vedlejší verzí.

V Linuxu je opravdu běžné, že verze knihovny bude stejná jako číslo verze balíčku. To má své pro a proti.

formalizace libtool

GNU libtool se hodně používá k vytváření dynamických knihoven a má formálnější systém verzování a má silnou logiku. Verzovací systém libtool pro sonames funguje velmi dobře a je převzat do složitých knihoven, aby bylo vše v pořádku.

V libtool je verzování jako pod:

libmylib-aktuální .vydání .věk

V rámci libtool je myšlenka, že jak se knihovny vyvíjejí, budou přidávat a odebírat funkce.

Řekněme, že vyvíjíte knihovnu. Začněte tím, že použijete verzi 0.0.0 .

Nyní řekněme, že opravíte několik chyb, pouze zvýšíte vydání číslo.

Nový název by tedy byl libmylib.0.1.0 nebo libmylib.0.2.0 atd. pro každé vydání, které pouze opravuje chyby, ale nemění žádné z ABI.

Po cestě říkáš. Fuj! Tuto dílčí funkci jsem mohl udělat lépe, takže přidáte novou sadu funkcí, abyste udělali něco lepšího, ale protože ostatní stále používají vaši knihovnu, stále tam necháte starou (zastaralou) funkci.

Pravidla jsou uvedena níže:

1. Začněte s informací o verzi „0:0:0“ pro každou knihovnu libtool.

2. Aktualizujte informace o verzi pouze bezprostředně před veřejným vydáním vašeho softwaru. Častější aktualizace jsou zbytečné a pouze zaručují, že se číslo aktuálního rozhraní rychleji zvětší.

3. Pokud se zdrojový kód knihovny od poslední aktualizace vůbec změnil, zvyšte revizi („c:r:a“ se změní na „c:r+1:a“).

4. Pokud byla od poslední aktualizace přidána, odstraněna nebo změněna nějaká rozhraní, zvyšte aktuální a nastavte revizi na 0.

5. Pokud byla od poslední veřejné verze přidána nějaká rozhraní, zvyšte stáří.

6. Pokud byla některá rozhraní od poslední veřejné verze odstraněna nebo změněna, nastavte věk na 0.

Více si o tom můžete přečíst v dokumentaci libtool

Aktualizovat...

Následuje komentář, že moje vysvětlení obsahuje chybu. Není, což vyžaduje trochu více podrobností, než je možné vložit do komentáře k odpovědi, viz níže.

Původní námitka

Zde je chyba:na linuxu je verze formlibmylib.(aktuální-věk).release.age, kde závorky označují výraz, který má být vyhodnocen. Například GLPK 4.54 withcurrent:revision:age =37:1:1 na linuxu nainstaluje knihovnu filelibglpk.so.36.1.1. Další informace naleznete např. na .

Odmítnutí

TLDR:autotools.io není autoritativní zdroj. Vysvětlení

Zatímco Flameeyes je úžasný vývojář a je jedním ze správců Gentoo, byl to on kdo udělal chybu, a vytvořil „pravidlo“ volné interpretace specifikace libtool. I když to v 99 % případů nenaruší systémy, pokud bychom měli postupovat ad-hoc způsobem aktualizace aktuálního :

Základní pravidla pro práci s těmito hodnotami jsou:

Vždy zvyšte hodnotu revize.

Zvyšte aktuální hodnotu, kdykoli bylo přidáno, odebráno nebo změněno rozhraní.

Zvyšte hodnotu věku pouze v případě, že změny provedené v ABI jsou zpětně kompatibilní.

pak pokračuje a říká, že při udržování více verzí Gtk by bylo nejlepší jednoduše přidat verzi knihovny do knihovny NAME a jednoduše vypsat číslo verze. (stejně jako v GTK+):

V této situaci je nejlepší možností připojit část informací o verzi knihovny k názvu knihovny, jehož příkladem je soname libglib-2.0.so.0 Glib. K tomu musí být deklarace v souboru Makefile.am tato:

lib_LTLIBRARIES = libtest-1.0.la

libtest_1_0_la_LDFLAGS = -version-info 0:0:0

No, to je jen blbý přístup k tomu, jak využít sílu dynamického propojení a verzování s rozlišením symbolů! Říká, že to prostě vypněte. Koňští buřiči! Není divu, že i zkušení vývojáři mají potíže s budováním a údržbou projektů s otevřeným zdrojovým kódem a neustále narážíme na to, že binární soubory umírají pokaždé, když se instalují nové verze knihoven (protože se navzájem blokují).

Přístup k verzování libtool je VELMI DOBŘE PROMYŠLENÝ . Je to algoritmus a jeho kroky jsou uspořádané pokyny 1 do 6 se mají dodržovat pokaždé, když dojde k aktualizaci kódu dynamicky propojené knihovny.

Pro nové i současné vývojáře si je prosím pozorně přečtěte a představte si, co se stane s číslem verze knihovny během životnosti vašeho úžasného softwaru. Pokud tak učiníte, všimnete si, že každá část dříve propojeného softwaru bude vždy správně používat nejaktuálnější a nejpřesnější verzi vaší úžasné knihovny a žádnou z nich se někdy navzájem bouchnou nebo dupou, A nikdy nemusíte přidávat rozkvetlé číslo do názvu vaší knihovny (pokud to není pro potěšení nebo pro estetiku).