Statické linkování balíků je hloupost

21.6.2010 16:22 | Přečteno: 3558× |

DWDův blog opěvující nádherný nový staticky linkovaný svět není první a určitě ani poslední pokus opravit jeden problém výměnou za jiný. Tenhle konkrétní pokus je celkem elaborovaný, takže by stál za podrobnější komentář. Tady je.

1. Balíky můžou být v Linuxu linkované dvojím způsobem: Buď staticky nebo dynamicky.

   Omyl, linkují se binárky, které se balí do balíků společně s jinými soubory. Tahle drobná nepřesnost vede bohužel dále v textu k naprosto zcestným závěrům. Nadále budu statický balík považovat za běžný balík se staticky slinkovanými binárkami nebo s přibalenými dynamickými knihovnami (takhle se obvykle distribuují uzavřené komerční programy, pro naše účely je to totéž)

2. Výhoda dynamicky linkovaných balíků je ta, že se šetří místo na disku … Další výhoda je, že se šetří paměť

   Největší, ale zcela opomenutá výhoda je, že jedinou instanci binárky/knihovny lze snáze udržovat a upgradovat. Dnešní systémy mají tisíce knihoven a i jednoduché programy linkují mnoho z nich. Kdyby bylo všechno staticky linkované, vyžadoval by upgrade jedné knihovny reinstalaci mnoha balíků. zlib, jpeg nebo glib jsou příklady malých knihoven kde by kilobajtová změna reinstalovala prakticky celý systém. A i u méně exponovaných knihoven rozměry závisejících balíků podstatně převyšují velikost samotné knihovny - to je koneckonců princip celé věci. Neupgradovat všechny závislé balíky není řešení. Většina upgradů záplatuje nějaké chyby, tudíž o ně budu stát. Hlavně se ale nemůžu vyhnout upgradům které záplatují díry bezpečnostní.

3. U statických balíků neexistuje tak zvané peklo závislostí.

   A hned první tragicky omyl způsobený záměnou balíku za binárku. Závislosti jsou vlastnosti balíku a problémy s nimi jsou způsobeny špatně zabaleným balíkem nebo špatným balíčkovacím systémem. Statickým linkováním nebo balením knihoven se lze sice těmto problémům vyhnout, ale to je léčení příznaků místo příčin.

4. Ale musíme myslet taky na takové lidi, kteří nemají přístup k internetu. Ti nemůžou využít automatické řešení závislosti

   Ditto, autor potřebuje změnit balíčkovací systém na takový, který umí vyčíslit závislosti předem. Třeba můj systém (portage) má možnost nechat si všechny závislosti vypsat do souboru vhodného k předhození wgetu. Dokonce jsem tak i jeden systém nainstaloval.

5. Statický balík je kompatibilní s různými distribucemi a verzemi Linuxu, je víceméně univerzální.

   Za prvé, čistě statickou binárku nelze ve skutečnosti udělat. I když vše slinkujeme se -static, bude binárka z ne úplně triviálních důvodů za běhu linkovat část libc. Bude sice podstatně odolnější, protože libc se mění málo, ale stoprocentní kompatibilita to není. Za druhé, což je mnohem důležitější, statické linkování neřeší změny v API, resp. řeší je tím, že jim brání. Přitom právě to je největší problém při přenášení balíků mezi distribucemi. Třeba balík z blbuntu nebude na mém systému chodit, ať už je slinkovaný jakkoliv, prostě proto že nemám Pulse Audio. Doma, nemaje tiskárnu, neběhám cups démona. Můžu mít/nemít FAM nebo jiné démony, jiný layout filesystému a práv, bezpečnostní moduly, adresářové služby, změny v kernelu et cetera et cetera. Přenositelnost mezi distribucemi a verzemi je podstatně složitější problém než jen linkování.

   Jediná spolehlivá metoda je pokusit se zastavit čas a neupgradovat vůbec nic. Na to ale není třeba statické linkování.

Zbytek textu jen dále rozvíjí tenhle drobný omyl do absurdních rozměrů, takže se nebudu opakovat.

Je tu ale ještě jeden háček který autor nevzal v úvahu, a to je dopad na vývoj. Statické linkování klade další práci na bedra vývojáře. Autoři takových programů by museli pečlivě sledovat všechny knihovny které linkují a podle potřeby vydávat nové verze. Dokonce i když sami nezmění ani řádku. Nejenom, že je to mnohem více práce, ale je to v důsledku mnohem náchylnější k problémům. Ostatně se to děje, stává se, že autor nějakého balíku takto obejde systémovou knihovnu (častý terč je zlib) a dříve či později to skončí průšvihem. Je to logické, vývojář má úplně jiné starosti než se starat o cizí knihovny, a dynamické knihovny kromě jiného umožňují odpovědnost soustředit v rukou vývojáře knihovny, který by měl vědět nejlíp. Spousta potíží vzniká z toho, že se sekne (klasicky když změní ABI a nezvedne verzi), ale mnohem, mnohem častější případ je, že se rozhodne správně, a tím ušetří práci všem ostatním. Nejviditelnější je to na bezpečnostních problémech - upgrade sdílené knihovny zalepí všechny linkující programy bez čekání až jejich vývojáři zareagují. Ani o tom nemusí vědět.

Co z toho plyne? Statické linkování může opravdu ušetřit nějaké problémy, ale dovedeno do důsledků je jich daleko méně, než si může neznalý člověk myslet.        

Komentáře

[Radek Miček]

Za prvé, čistě statickou binárku nelze ve skutečnosti udělat. I když vše slinkujeme se -static, bude binárka z ne úplně triviálních důvodů za běhu linkovat část libc. Bude sice podstatně odolnější, protože libc se mění málo, ale stoprocentní kompatibilita to není.

Compiling without libc

[rADOn]

To taky. Ale ja mám na mysli to, že libc natahuje knihovny k překladnu uživatelských jmen na ID etc. podle nastavení /etc/nsswitch.conf. A to i když je zbytek libc linkován staticky. Což je logické, během překladu nemůže vědět jestli na cílovém systému nebude náááhodou třeba NIS

[Michal Kubeček]

S NIS by se asi ještě jakž takž vypořádat dalo, ten se koneckonců používal ještě před nástupem NSS a PAM. Ale co LDAP, NT doména, čtečky čipových karet, snímače otisků a další věci, které třeba ještě ani neznáme?

[Grunt]

Ditto, autor potřebuje změnit balíčkovací systém na takový, který umí vyčíslit závislosti předem. Třeba můj systém (portage) má možnost nechat si všechny závislosti vypsat do souboru vhodného k předhození wgetu. Dokonce jsem tak i jeden systém nainstaloval.

Deb a Yum je zase umějí postahovat do předem zadaného adresáře.

[kolcon]

emerge samozrejme taky (emerge -f)

[kotyz]

zrovna na tomhle mi ted chcipa xnviewmp, sou k nemu pribaleny nejaky asi lehce priohnuty qt knihovny (maji xn v nazvu) [verze 4.6.2] a asi tam nejsou vsechny a tak to nejspis vola i nejaky dalsi ze systemu [verze 4.6.3] a pri startu to mekta Cannot mix incompatible Qt libraries a nespusti se. uz sem to hlasil v AURu a taky primo autorovi, ale oba delaji jako by to vsem fungovalo a zadnej problem neexistoval ...

[kotyz]

snad nejsem blbej a kdyz napisu ze to nefunguje tak to nefunguje a ne ze to blbe spoustim nebo sem se v tom hrabal. navic to driv fungovalo a zjevne to prestalo fungovat az nedavno spolecne s tim jak se upgradli qt knihovny v systemu na 4.6.3 ...

[chrono]

Mne ten balík XnViewMP-linux.tgz funguje aj bez nainštalovaného Qt4, takže tam musia byť všetky potrebné knižnice a problém je asi naozaj v niečom inom. Skúšal si spúšťať aj priamo xnview.sh z toho balíka?

Inak keď posielaš nejaké chybové hlášky, asi by bolo dobré použiť niečo ako LC_ALL=C xnviewmp (je to neuveriteľné, ale je pár ľudí, čo tomu českému textu nebude rozumieť). :)

[kotyz]

jo, na to ted pouzivam export LANG=C, ale ono to vetsinou nevadi, protoze to dulezity je tam stejne anglicky. a kdyby sis to precet cely, tak bys vedel ze sem spoustel binarku i skript a nefungovalo ani jedno.

[chrono]

Pozeral som len ten AUR link a tam sa o testovaní xnview.sh nič nepísalo. :)

Každopádne je zaujímavé, že sa ti do toho pletú systémové Qt knižnice, keďže XnView používa len názvy *Xn.so.4 (pravdepodobne práve preto, aby sa naozaj nepoužívali systémové knižnice).

Skús použiť LD_LIBRARY_PATH=./lib ldd xnview | grep Qt a potom v lib adresári LD_LIBRARY_PATH=. ldd *.so.4 | grep Qt či tam nenájdeš kde sa vlastne používa systémové Qt. (predpokladám ale, že žiadny problém nenájdeš, práve kvôli Xn v názvoch knižníc)

[kotyz]

ale je v nem link na forum xnview pro hlaseni bugu a tam to je

[kotyz]

[kotyz@behemot XnViewMP-026]$ LD_LIBRARY_PATH=./lib ldd xnview | grep Qt
        libQtWebKitXn.so.4 => ./lib/libQtWebKitXn.so.4 (0xb66f5000)
        libQtGuiXn.so.4 => ./lib/libQtGuiXn.so.4 (0xb5be3000)
        libQtCoreXn.so.4 => ./lib/libQtCoreXn.so.4 (0xb593d000)
        libQtXmlPatternsXn.so.4 => ./lib/libQtXmlPatternsXn.so.4 (0xb544c000)
        libQtNetworkXn.so.4 => ./lib/libQtNetworkXn.so.4 (0xb5315000)
        libQtSvgXn.so.4 => ./lib/libQtSvgXn.so.4 (0xb52bb000)
        libQtXmlXn.so.4 => ./lib/libQtXmlXn.so.4 (0xb5271000)

[kotyz@behemot lib]$ LD_LIBRARY_PATH=. ldd *.so.4 | grep Qt
libQtCore.so.4:
libQtCoreXn.so.4:
libQtGui.so.4:
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb6a07000)
libQtGuiXn.so.4:
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb69bd000)
libQtNetwork.so.4:
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb73a8000)
libQtNetworkXn.so.4:
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb74ea000)
libQtOpenGL.so.4:
        libQtGuiXn.so.4 => ./libQtGuiXn.so.4 (0xb6bef000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb6949000)
libQtOpenGLXn.so.4:
        libQtGuiXn.so.4 => ./libQtGuiXn.so.4 (0xb6c41000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb699b000)
libQtSvg.so.4:
        libQtGuiXn.so.4 => ./libQtGuiXn.so.4 (0xb6c63000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb69bd000)
libQtSvgXn.so.4:
        libQtGuiXn.so.4 => ./libQtGuiXn.so.4 (0xb6c1b000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb6975000)
libQtWebKit.so.4:
        libQtXmlPatternsXn.so.4 => ./libQtXmlPatternsXn.so.4 (0xb60d3000)
        libQtGuiXn.so.4 => ./libQtGuiXn.so.4 (0xb560f000)
        libQtNetworkXn.so.4 => ./libQtNetworkXn.so.4 (0xb54d8000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb5231000)
libQtWebKitXn.so.4:
        libQtXmlPatternsXn.so.4 => ./libQtXmlPatternsXn.so.4 (0xb61ef000)
        libQtGuiXn.so.4 => ./libQtGuiXn.so.4 (0xb572b000)
        libQtNetworkXn.so.4 => ./libQtNetworkXn.so.4 (0xb55f4000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb534d000)
libQtXml.so.4:
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb75c9000)
libQtXmlPatterns.so.4:
        libQtNetworkXn.so.4 => ./libQtNetworkXn.so.4 (0xb71d7000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb6f31000)
libQtXmlPatternsXn.so.4:
        libQtNetworkXn.so.4 => ./libQtNetworkXn.so.4 (0xb7153000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb6ead000)
libQtXmlXn.so.4:
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb752b000)
        libQtGuiXn.so.4 => ./libQtGuiXn.so.4 (0xb6d8a000)
        libQtCoreXn.so.4 => ./libQtCoreXn.so.4 (0xb6ae4000)

[kotyz]

je tam nakej problem? ja nevidim nic ...

[chrono]

Vyzerá to úplne normálne, takže nie je jasné, prečo sa do toho mieša systémová Qt knižnica.

Jediné, čo sa asi dá použiť je už asi len strace.

[Semo]

Podobny problem bol v opere asi pred pol rokom, ktora si nastavovala LD_LIBRARY_PATH ku vlastnej verzii Qt a potom nefungovali Qt programy spustane operou (napr. okular). Takze som si musel napisat wrapper, ktory odnastavil LD_LIBRARY_PATH a spustil okular 9ktory uz potom videl na systemove Qt a fachal). Uz to opravili.

[rADOn]

Jestli to bali Qtcka tak je problem v tom ze to bali Qtcka. To je proste prasarna prasacka a autor ty veci patri zastrelit. Protoze:

1. bud pribali uplne vsechno od zlib az po libc, coz "staticky balicek" podle evangelia DWD, a budou s tim problemy uvedene v blogu (teoreticka moznost, nikdo neni tak silenej)
2. nebo pribali jen neco (treba samotnou Qt a jeji primy zavislosti) coz je pruser ktery jen ceka az se stane. Protoze pachatel nemuze dopredu vedet kdy neco ze systemu nalinkuje knihovnu ktera je pribalena. jenze jelikoz je to linkovany ze systemu, ma to jine ABI a zacne bengal. Tragicky na tom je, ze pachatel ktery to zpusobil ma obe tyhle kopie stejny, tudiz jemu to bude fungovat (pokud ty knihovny nemaji nejaky vnitrni stav kteru muze v kopiich kolidovat) a proto se to skutecne stava.

[chrono]

Tie Qt knižnice používajú iba knižnice, ktoré sú dostatočne stabilné a používané, takže taký problém nastane málokedy (a ak majú tie knižnice zmenené ABI, tak sa minimálne zmení soname).

[Bubak]

Trochu bych se zastal statickeho linkovani. Proste obcas zdrojaky publikovat nemuzu a tohle je rozumna zaruka ze to pojede i za 5 mozna i 10 let.

BTW: binarku jde zkompilovat s UCLib ci necim podobnym, pak nezavisy ani na libc.

[chrono]

uClibc sa síce použiť dá, ale je to potom prenositeľné medzi rôznymi jadrami?

[rADOn]

Teoreticky ano, jadro ruci za zpetnou kompatibilitu ABI. Ale jsou ruzny veci ktery "se nemaji delat, ale muzou se provadet" protoze nejaky nespravny, ale nefatalni chovani jadro nehlida. A kdyz po nejake dobe zacne, aplikace ktere to delaji blbe se sypou...

Navic ani staticky slinkovana libc neresi dynamicke NSS moduly, viz prvni thread. I kdyz bys nejak zabetonoval standartni moduly - shadow, NIS etc, stejne to vybouchne kdyz nekdo pouzije treba LDAP. A libc neni zdaleka jedina knihovna ktera muze za behu dlopen()ovat knihovny o kterych staticky balic nema paru. Treba PA je krasnej priklad. A ostatne ALSA to dela taky.

[rADOn]

Za deset let takova binarka pobezi tak, jako dnes bezi deset let stary binarky - pokud vubec pobezi (kdo ma v kernelu podporu a.out at zvedne ruku) pak v 32bitovy emulaci, neznaji nptl, nechapou inotify, neumi V4L, nikdy neslysely ani xinerame natoz o xrandr, dbus jim zcela unika, zvuk serou do OSS, to cely v nejakym odpornym AWTu nebo athene... mam pokracovat?

Klidne bych souhlasil ze jako nouzovka je to lepsi nez nic, ale jeste predtim by bylo potreba zastrelit vsechny vendory kteri na to spolehaji a tvari se jako ze je chyba uzivatele, ze nema zastaraly system.

Navic se to nevylucuje - opera treba distribuuje jak statickou tak dynamickou verzi. Vubec opera je asi jediny closed source vendor ktery ma baleni a redistribuci dobre udelane. Jeste tak mozna nvidie.

[Miloslav Ponkrác]

Největší lži podle mých zkušeností bývají v linuxových článcích, které se snaží vyvracet mýty. Ani tento článek není výjimkou v možství servírovaných lží.

Nicméně dále to komentovat nebudu.

Snad jen dejte si pozor na linuxové články, které se snaží vyvracet nějaké mýty, nebo hloupost. Obsahují ve většině případů mnoho lží dané především zaujatostí autora.

Dále reagovat nebudu, je to upozornění pro ty přemýšlivé.

[nezmar]

Jo, clanok je podobne ako predloha mierne demagogicky - gentoo uzivatelia potvrdia ze nie vzdy plati ze jedna DSO nahradi inu verziu tej istej DSO hoci sa aj soname nezmenilo.

Niekedy sa da zjednodusit nasadenie ked sa niektore exotickejsie kniznice prilinkuju staticky. Inokedy sa da zase ziskat dost velky vykon - staticka versus dynamicka verzia kniznice AGG dava 30% vykonu navyse. DSO zaberaju na x86 platforme ebx register pre PLT ako aj pridavaju reziu niekolkych instrukcii pre kazdy CALL, atd, atd.

[Michal Kubeček]

Na druhou stranu, kdysi jsem zkoušel testovat ten overhead na dynamicky linkovanou knihovnu a s překvapením jsem zjistil, že v mém případě (platforma AMD64, gcc) je z nějakého důvodu verze s dynamicky linkovanou knihovnou rychlejší než staticky linkovaná. Ale i jinde ten rozdíl bývá minimální.

[pozortucnak]

A co říkáte na gobolinux?

[chrono]

Čo konkrétne máš na mysli? To, že podľa nich je obvyklá štruktúra adresárov v Linuxe zlá a tak namiesto /usr/lib a /usr/bin majú /System/Links/Libraries a /System/Links/Executables?

[xm]

GoboLinux pokud vím používá dynamicky linkované knihovny. Liší se jen adresářovou strukturou.

[l4m4]

Statickým linkováním nebo balením knihoven se lze sice těmto problémům vyhnout,

I to pouze omezeně. Velká část dependency hellu vzniká jinými typy závislostí než závislostmi na dynamicky linkovaných knihovnách.

[DWD]

A co říkáte na gobolinux?

Vynikající! Něco takového jsem už dlouho chtěl. Proti jiným distribucím je to velký pokrok. Výhoda je, že každý program má svůj podadresář a v něm všechny soubory, které k tomu programu patří. Všechno je přehledně uspořádané, roztříděné a je pěkně vidět, co k čemu patří. Na rozdíl od jiných distribucí, ve kterých jsou soubory všech programů různě rozhazané po celém systému, bez jakéhokolv třídění, je v tom nepořádek a je to velmi nepřehledné. Já vím, že existují skripty, ve kterých je zapsané, ke kterému programu který soubor patří, takže přidat nebo odebrat program, se vším, co k němu patří, není problém, ale není to ono. Přijde mi to stejné, jak kdybych měl nepořádek ve věcech a všechny věci různě rozhazané a netříděné a vůbec neměl uklizené a místo úklidu bych si pořídil sešit, do kterého si jenom zapíšu, kde mám kterou věc, abych ji našel. Právě proto se mi Gobo Linux líbí, protože mám rád pořádek. Líbí se mi taky jakým způsobem jsou sestavené balíky, způsob instalace a odinstalace balíků, a taky to, že má oproti jiným distribucím přehlednější kompilací. Zřejmě bych našel i další výhody této distribuce.

Začal jsem se o Gobo Linux zajímat, ale mám pocit, že se asi přestal vyvíjet, protože nikde na internetu jsem neobjevil novější verzi, než z roku 2006. Stejně tak novější články jsem na internetu nenašel. Když jsem se díval do repozitářů Gobo linuxu, verze programů jsou tam dost zastaralé a některé novější programy tam nejsou vůbec. Například Audacity je tam nanejvýš ve verzi 1.2.3, Jamin tam není vůbec a tak dále. Tak by mě zajímalo, jak je to s vývojem této distribuce. Opravdu se přestala vyvíjet? Pokud se to přestalo vyvíjet, je to škoda, protože nic tak vynikajícího jsem neviděl. Nebo se změnil jenom název, jako například Mandrake na Mandrivu?