Dotaz: Dynamické linkování

[Dušan Renát]

Mám program v C++ a používám v něm mimo jiné knihovnu SDL_gfx. Mám ji dynamicky linkovanou, tj. soubor .so distribuuju s programem. Mám tedy hlavní adresář projektu, kde mám mimo jiné Makefile, a adresář lib v něm, kde je knihovna. A teď:

Knihovna musí mít název libSDL_gfx.so, jinak ji linker při zadání -lSDL_gfx a -rpath=./lib nenajde už při linkování. Pokud ji tak pojmenuju, při spouštění mi to zařve " error while loading shared libraries: libSDL_gfx.so.4: cannot open shared object file: No such file or directory". Netuším, proč se ptá na tuto verzi knihovny (pokud to číslo vůbec znamená verzi) a proč to nefunguje, když například vytvořím symbolický odkaz na původní soubor (takhle jsem to viděl udělané u sebe v /usr/lib).

Dokáže mi prosím někdo vysvětlit, jak funguje dynamické linkování s těmahle číslama a jak to udělám, aby to našlo tu knihovnu?

Odpovědi

[frr]

Není to náhodou tak, že rozhoduje to, co si myslí systémový ldconfig?

Tj. pokud soubor přejmenujete, tak na systému, kde má binár nakonec běžet, je potřeba upravit ld.so.conf (přidat správnou cestu) a spustit /sbin/ldconfig, aby se změna promítla do ld.so.cache (nebo jak se to ve Vašem distru jmenuje). Binár dynamicky slinkovaný na jednom systému proti jedné verzi knihovny (jménu souboru.so) bude fungovat transparentně i na jiném systému kde je jiná verze téže knihovny (jiné číslo ve jménu souboru .so) - za předpokladu, že na cílovém systému o knihovně ldconfig ví, a za důležitého předpokladu, že se mezi verzemi nezměnily Vámi používané prototypy funkcí a obsahy structů (jinak segfault).

Pokud chcete "distribuovat správnou verzi knihovny se svým vlastním binárem", asi Vám nakonec nezbyde než to slinkovat staticky :-|

Hint: zkuste se mrknout, jaké soubory to hledá, pomocí utility "strace" .

(Jak to sakra dělá Gobo Linux?)

A hele, ono je možné natáhnout knihovnu i explicitně / programově - ale z Cčka je to krkolomné.

http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/index.html

http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html

Žádná transparentnost ala perlový Dynaloader. Je to dáno rozdílem mezi staticky typovaným kompilátorem (C) a dynamickým interpreterem (Perl). Když chcete v Cčku volat funkci, třeba i nepřímo přes pointer, musíte už při kompilaci znát její prototyp (ne jméno, ale počet a typy argumentů). Nepříjemným důsledkem pro Vás je, že i když ve Vašem případě znáte předem kompletní hlavičkový soubor knihovny, tak pokud byste ji chtěl loadovat explicitně přes dlopen(), budete si muset ve Vašem kódu explicitně deklarovat prototyp ke každé funkci, kterou chcete použít (a budete ji muset volat přes pointer). Opravte mě někdo jestli kecám...

[vencas]

-rpath se používá až při spouštění, takže když máte ./lib, bute to relativně k adresáři, ze kterého spouštíte; to asi nechcete... dejte tam absolutní cestu. Pro linker při linkování potřebujete -L./lib.

Mrkněte na výstup "ldd binárka", potom taky RTFM ld.so, zvláště LD_DEBUG, RPATH a $ORIGIN.

[l4m4]

Než -rpath raději bych nastavil LD_RUN_PATH/LD_LIBRARY_PATH, což umožní knihovnu přesouvat.

[l4m4]

Verze knihovny určuje verzi implementovaného rozhraní knihovny (a je zakódována v binárce). Ta musí odpovídat, jinak se to neslinkuje, protože program vyžaduje rozhraní, které knihovna neimplementuje. Ve skutečnosti je to ovšem trochu složitější, pro podrobný popis viz

http://sources.redhat.com/autobook/autobook/autobook_91.html

Soubor libknihovna.so bez verze je pouze link na jednu z verzí, které máš nainstalovány -- typicky na tu poslední, což zařizuje ldconfig -- a používá se pouze v čase kompilace. Run-time se vždy hledá knihovna opovídající verze.

Toto vše platí, pokud se bavíme o normálních knihovnách, ne o dlopen()ovaných modulech, kde se to většinou řeší jinak.

Takže normální situace je

Run-time soubory:

libknihovna.so.4.0.2 -- vlastní knihovna

libknihovna.so.4 -- link na libknihovna.so.4.0.2

libknihovna.so.7.0.0 -- jiná verze knihovny, s jiným interface

libknihovna.so.7 -- link na libknihovna.so.7.0.0

Build-time soubory:

libknihovna.so -- link na libknihovna.so.7 (resp. 7.0.0)

[Michal Kubeček]

Soubor libknihovna.so bez verze je pouze link na jednu z verzí, které máš nainstalovány -- typicky na tu poslední, což zařizuje ldconfig -- a používá se pouze v čase kompilace.

Přesnější by bylo napsat při linkování (při kompilaci potřebujete jen hlavičkové soubory).

[Dušan Renát]

Abych odpověděl tak nějak všem ... ano, rpath funguje až při spouštění, což je přesně to, co chci - chci to dynamicky slinkovat a pak tu dynamickou knihovnu přidat do podadresáře, aby se při překládání i spouštění odtud mohla použít. V praxi by to vypadalo spíš tak, že bych prohlásil, na kterých všech knihovnách to závisí, ať si je uživatel sežene ... na většině systémů to není žádný problém. Ale teď tenhle program odevzdávám jako zápočet a mám zadáno, že to má být balíček, který půjde sám o sobě přeložit - tj. už musí všechny dynamické knihovny obsahovat.

Jaký je přesně problém v tom, když ten soubor dynamické knihovny zkopíruju do adresáře s programem, slinkuju to s tím a zadám rpath tak, aby se to při spouštění hledalo tam, kde jsem to nakopíroval (což JE relativně k aktuálnímu adresáři, NE absolutní cesta).

Problém je v tom, že prohlásí, že nenachází soubor libSDL_gfx.so.4, a to i tehdy, když tam ten soubor je. Toto je problém a toto bych prosil, aby jste mi tu pomohli vyřešit. Ne navrhovat změny cest pro hledání knihoven ... což na systému, ke kterému nemám přístup, těžko udělám.

[Dušan Renát]

Ještě se to pokusím vysvětlit líp a jednodušeji.

Můj program potřebuje dynamickou knihovnu ke slinkování a spuštění. Na systému, kam to odevzdávám, ta knihovna není a nebude. Chci ji poskytnout se svým programem, v jednom z podadresářů, v přeložené podobě (.so), aby se na tom vzdáleném systému program mohl přeložit a spustit. Aby při překladu a spouštění byla na vzdáleném systému knihovna nalezena, používám -L a --rpath na ten podadresář, kam jsem knihovnu umístil. Knihovna není nalezena. Nevím proč.

[Dušan Renát]

Ještě jedna oprava. Knihovna není nalezena PŘI SOUŠTĚNÍ. Při linkování ano. Předpokládám problém v tom parametru -rpath.

[Vojtěch Horký]

Možná jsem úplně mimo, ale pro linkování jsem taky volal GCC (ne přímo linker) a tuhle cestu jsem zadával parametrem -R. Něco jako (snad jsem zkopíroval tu správnou část):

XLINKER=-Xlinker # or empty for Solaris
...
$(CC) $(LDFLAGS) -o $@ -L. $(XLINKER) -R $(XLINKER) . $(OBJFILES)

[frr]

Proč to neslinkujete staticky?

Jinak bych se trochu bál, že knihovna zkopírovaná jako hotový binární soubor bude mít další svoje vlastní "dependencies", které na cílovém systému mohou haprovat - ale konkrétně s SDL nemám v tomto směru zkušenosti...