Statické linkování balíků je hloupost (diskuse)

[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?