Nebojíme se kompilace - I (teorie)

14. 10. 2004 | Petr Krčmář

Články - Nebojíme se kompilace - I (teorie)  

Jednou z nočních můr linuxových začátečníků je vlastní kompilace programů ze zdrojových kódů. Většina z nich se jí snaží co nejdéle vyhýbat, dříve či později jsou ale přesto nuceni ji využít. Jak na ni si ukážeme v našem novém seriálu.

Tento seriál je určen začátečníkům, kteří neví, co je to překlad, případně neví jak na něj. Některé popisy jsou proto značně zjednodušeny.

V GNU/Linuxu, stejně jako v dalších unixových systémech, se velmi často používají překladače z rodiny gcc, kterými se také budeme v našem seriálku zabývat.

Překladač provádí přeměnu zdrojového kódu čitelného člověkem na binární kód, který je čitelný pro procesor. Ovšem čitelný pro konkrétní procesor. To, co umí i386, neumí Alpha a podobně.

Nutnost kompilace vznikla postupným vývojem. V dřevních dobách programování psali programátoři svá díla přimo ve strojovém kódu. Neměli jinou možnost, pokud chtěli, aby procesor věděl, co má dělat. Strojový kód je však pro větší projekty nevyhovující kvůli tomu, že zvládá pouze atomární kroky a složitější funkce je třeba velmi rozvlekle rozepisovat. Proto vznikly takzvané vyšší jazyky, které mají proti strojovému kódu řadu výhod:

• Jsou lépe čitelné pro člověka.
• Jsou na první pohled lépe srozumitelné.
• Díky tomu se v nich lépe hledají chyby.
• Programátor se může více soustředit na obsah než na formu.
• Překladač je pak může přeložit pro více platforem a systémů.
• Lze je dodatečně optimalizovat pro konkrétní procesor.

Toto jsou některé důvody, které programátory vedou k použití vyšších jazyků. V těch napíší své programy a pustí je do světa. Protože se pohybujeme ve světě svobodného software, máme ke všem aplikacím zdrojový kód. Ten nám umožňuje programy zkoumat, opravovat a měnit. Abychom je poté mohli na svých počítačích spustit, musíme provést zmíněnou kompilaci.

Samostatnou kapitolou je pak optimalizace programu. Ta nám umožní během překladu zohlednit charakteristiky jednotlivých procesorů, a tím zrychlit následné provádění strojového kódu. Příklad: procesory novějších generací obsahují instrukce, které umožňují provádět rychleji některé matematické funkce. Pokud je tedy v binárním programu kompilátor použije, zvýší se jeho efektivita. Nevýhodou pak je, že takto přeložený program nám nepoběží na procesoru nižší generace. Programátora ovšem výsledná podoba nezajímá, tu určuje až překlad (respektive parametry předané překladači).

Tvůrci distribucí tyto překlady obvykle provedou za nás a my už získáme hotový binární (zkompilovaný) balíček, který jen rozbalíme na svůj disk pomocí instalačního procesu a můžeme začít program používat. Může však nastat několik situaci, které nám tento běžný postup znemožní:

• Potřebujeme program nějak upravit a musíme proto zasáhnout do zdrojových kódů.
• Neexistuje balíček pro naši distribuci.
• Chceme provést vyšší stupeň optimalizace.
• Potřebujeme balíček pro nestandardní architekturu.
• Balíčky, které máme, nejsou s knihovnami v naší distribuci kompatibilní.

Poslední možnost si popíšeme podrobněji, protože se nás pravděpodobně budou týkat nejčastěji. V moderním operačním systému provádí většina programů velmi podobné operace. Aby se každý programátor nemusel zabývat implementací obecných funkcí, existují takzvané knihovny. Tyto knihovny obsahují nejčastěji používané kódy, které může libovolný program použít. Jednoduše zavolá funkci v knihovně a ta nějak samostatně proběhne. Programátora tedy implementace vůbec nezajímá, stačí mu, že ví jak funkci zavolat.

Knihovny se do systému instalují samostatně (obvykle bývají v samostatných balíčcích) a bez nich pochopitelně programy fungovat nemohou. Bez nich by prostě kus kódu chybělo a program by nemohl některé funkce vůbec provádět. Správné knihovny ve správných verzích jsou tedy bezpodmínečnou nutností. Tady narážíme na zakopaného psa.

Nevýhoda knihoven se projeví ve chvíli, kdy se například snažíte do starší distribuce nainstalovat novější balíček. Tento balíček byl samozřejmě přeložen v novější verzi distribuce, která obsahuje také novější verze knihoven než ta vaše. Říkáme, že je program přeložen proti novější knihovně. Jelikož se jedná o binární balíček, je již pevně sestaven a očekává, že bude mít k dispozici knihovnu, proti které byl přeložen.

A nastává klasický problém závislostí, o kterém jste již jistě slyšeli. I kdyby se vám povedlo balíček nainstalovat, program nepoběží, protože nebude schopen s novou knihovnou komunikovat.

Chceme-li zjistit, které knihovny program potřebuje, můžeme použít příkaz ldd:

#ldd /bin/sh libtermcap.so.2 => /lib/libtermcap.so.2 (0xb75df000) libdl.so.2 => /lib/libdl.so.2 (0xb75db000) libc.so.6 => /lib/tls/libc.so.6 (0xb74a3000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)

V tomto případě je vše v pořádku a my vidíme, že žádná knihovna nechybí (v opačném případě bychom dostali místo cesty jen text "not found").

Jak z toho ven? Možností je několik:

• Nainstalovat novou knihovnu.

To ovšem nemusí být řešení - nová knihovna může být závislá na dalších knihovnách a ty pak na dalších a dalších a problém může přerůst až ve změnu půlky systému.

• Sehnat si balíček nového programu přeložený proti mojí distribuci.

Toto je samozřejmě ideální řešení, protože překlad už někdo udělal přede mnou. Ne vždy je to však možné.

• Zkompilovat si nový program vlastními silami.

Kompilaci vlastními silami si podrobně vysvětlíme a předvedeme na příkladu. Není to nic těžkého, protože člověk je tvor líný a vynašel si k tomuto účelu řadu automatických udělátek.

Ale o tom až příště.

Seriál Nebojíme se kompilace (dílů: 3)

První díl: Nebojíme se kompilace - I (teorie), poslední díl: Nebojíme se kompilace - III (ladíme).
Následující díl: Nebojíme se kompilace - II (praxe)

Diskuse k tomuto článku

[klassik]

Bry den. Mam dva mensi dotazky. V clanku se pise, ze programatora implementace knihoven vubec nezajima a staci mu jen vedet jak funkci zavolat. Pokdu teda v systemu knihovny nejsou, tak se pri kompilaci knihovny vytvori? A pokud chceme zjistit jake knihovny program potrebuje pouzijeme prikaz ldd.Nicmene me neni jasne kdy a v kterem korenu ho pouziji.(Vim man ldd nicmene exampl mi neni jasny v tom smyslu ze pokud mam balicek treba mplayer tak jak zjistim jake knihovny potrebuje)

[Jiří Svoboda]

Pokud pri kompilaci v systemu knihovny nejsou, muze nastat jeden ze dvou scenaru:
1) Bud program knihovnu vyzaduje a pak nahlasi chybu (vetsinou uz hned pri './configure') a nezkompiluje se.
2) Program potrebuje knihovnu jen pro urcitou funkcnost a pokud ji nenajde, zkompiluje se bez teto funkcnosti.
Typicky napr. zmineny mplayer. Pri kompilaci hleda mj. knihovny s kodeky. Pokud prislusnou knihovnu najde, zkompiluje se s jeji podporou (napr. libdv pro DV video). Pokud ji nenajde, zkompiluje se bez jeji podpory, ale jeji dodatecne pridani do systemu (coz znamena bud instalaci z binarky a nebo kompilaci) funkcnost automaticky neprida, mplayer se musi znovu zkompilovat.
Neuvazuji ted pripad, pokud je opravdu knihovna soucasti nejake aplikace a dale neuvazuji staticke/dynamicke linkovani, ktere urcite bude popsano v nekterem z dalsich dilu.

S ldd muze byt jediny problem a to ten, ze ldd nehleda program (svuj parametr) v ceste. Takze se musi uvest plna cesta. Tzn. napriklad:

ldd /usr/bin/mplayer

nebo

ldd `which mplayer`

[klassik]

Diky. Naprosto vycerpavajici odpovedi

[kowy]

Seš naprosto super. Fakt díky díky díky. Delši dobu totiž přemýšlím, jak se jmenuje program, terý mi vrátí cestu ke spouštěnému programu. Věděl jsem, že se tak jmenuje, jen se mu z hlavy vykouřilo to jedno slovíčko WHICH. Nahrazoval jsem si to pomocí locate či find|grep, ale to není ono. Ještě že máme ten internet, jinak bych s tou svou hlavou musel něco udělat

[Michal Kubeček]

Myslíte něco jako:

alias xwhich='find `echo $PATH | tr : \ ` -name'

Ale to je spíš náhrada za příkaz 'where' z tcsh.

[Yoss]

Ja sa ospravedlnujem vopred za blbu otazku (a uz vidim tie posmesne odpovede), ale som uplny zaciatocnik a dufam, ze sa najde aspon jeden dobrodinec, ktory mi pomoze. Stale nerozumiem tomu ldd. Mam SUSE a nemozem dostat z ldd, aby mi vypisal kniznice ktore program potrebuje. Neviem ako ho pouzit. Mam napr v adresary software ulozeny a roztarovany zdrojak v adresary napr moj_zdrojak. ked napisem ldd user/software/moj_zdrojak, vzdy mi vypise ze nevie najst adresar. Jednoducho nepoznam syntax prikazu (ten user, je samozrejme moj profil). Skusal som pisat cele cesty zacinajuce root aj cesty zacinajuce od profilu a adresara home, aj tym sposobom ze som vosiel do adresara kde mam zdrojak a napisat ldd, ale stale mi to nejde....

Diky za pomoc

[Stanislav Brabec]

Žádný takový program neexistuje (configure skript je tomu pouze nápomocen).

ldd umí vypsat knihovny vyžadované hotovou binárkou, což vám nepomůže - RPM si to hlídá samo, a kompilátorem chybějící knihovnu nepřilinkujete. Cesta samozřejmě může být zadaná jakýmkoliv platným způsobem.

Příklad:

ldd /bin/ls

Pokud jste začátečník, použijte např. zdrojový RPM, který má v hlavičce BuildRequires, kde je vše potřebné vyjmenováno. Jinak sledujte výpis configure a kompilace, zanalyzujte protokol (config.log, výpis na konzoli), zjistěte, jaký soubor vám chybí, a pak hledejte ve správci balíků v YaSTu balíček, který potřebný soubor obsahuje.

[aaa]

Chtěl bych se zeptat, zda existuje nějaká možnost (utilita?), jak bez větší námahy vygenerovat 'autoconf' skripty ('configure' atd.) z ručně vytvořeného Makefile? (Pokud možno automaticky bez ručního zásahu.) Jde mi o to, že někteří vývojáři nemají autoconf příliš v lásce, což většinou komplikuje život nejen při překladu, ale i při tvorbě balíčku. Díval jsem se sice do dokumentace k autoconf, ale jako neprogramátor jsem tomu ne zcela porozuměl...

[Stanislav Brabec]

To ne - to by bylo drbání levou rukou za pravým uchem. Automake slouží k přesně obrácené věci - z jednoduchého Makefile.am vytvoří komplexní Makefile.

Ale existují nástroje, které projdou zdrojáky a navrhnou, co by se mělo testovat apod.:

autoscan, příp. autoupdate pro aktualizaci, ifnames pro větvení programu, libtoolize pro knihovny, gettextize pro podporu lokalizace, intltoolize pro podporu lokalizace na desktopu atd.

Případně Linuxové IDE, kde naklikáte, co potřebujete, a ono si to vše vytvoří samo.

[Stanislav Brabec]

Nesetkal jsem se s tím, že by autoconf komplikoval tvorbu balíčku - ten jí naopak výrazně usnadňuje. Ani překlad nekomplikuje.

Jediné, co je opravdový problém, je napsat správně všechny soubory kolem. K tomu ještě drobné změny syntaxe přícházející s novými verzemi.

Dokumentace k těmto nástrojům není zrovna ideální - chybí tam HOWTO a ukázky, spousta maker je dokumentovaná jen ve zdrojácích.

Nejlépe je si najít nějaké články, hotové balíčky. Chyby pak řešit za pomoci Googlu (změna syntaxe postihne víc projektů).

[aaa]

Asi jsem se nevyjádřil úplně jasně - komplikují mi život ručně psané Makefiles, neboť z nich většinou nejde úplně jednoduše vygenerovat standardním postupem použitelný balíček. Naopak automaticky generovaný Makefile většinou žádné problémy nedělá. Takže bych potřeboval něco "hrozně chytrého", co by dokázalo projít ruční Makefile a vygenerovalo soubory potřebné pro použití autoconf. (Jestli plácám nesmysly, tak se předem omlouvám...)

[Stanislav Brabec]

Nevím o tom, a pochybuji, že by se to někomu kdy povedlo.

[kowy na centrum t cz]

Má to krapet nevýhodu, včera jsem si na Fedoře 1 upgradoval Gtk+ na nejnovější ze zdrojových kódů. Po dvouvečerním klání se to povedlo. OdRPMkoval jsem původní a dám make install. Výsledek je dost smutný, Xka naběhla, ale místo GDM na mě vyjukla černá obrazovka A jelikož na notebooku mám problém s framebufferem, tak ani textové terminály nejdou. Mno nemám se pouštět do takových šíleností, když tomu nerozumím.

Co ale považuju za podstatnější chybu, je že při instalování z dávek není možné udržovat pořádek na počítači. Z dlouhodobého hlediska je to neudržitelné. Když mám nainstalováno všechno přes balíčky, tak vím CO tam mám, KDE to mám a v JAKÉ to mám verzi. Když budu kompilovat páté přes deváté tak jak to zrovna "potřebuju" a samozřejmě smažu všechny zdrojáky, abych ušetřil místo na disku. Pak za půl roku nebudu vědět s jakými parametry jsem který program zconfiguroval, tudíž nebudu vědět, jak to odinstalovat. A pak už stačí zadat blbě parametry za configure a mám po žížalkách. Už se to nekorektně odinstaluje a na disku zbydou nějaké relikty V tom vidím problém kompilování z kódu. Prostě na produkční stroji (a tím myslím i svůj NB, na kterém pracuju) se za čas vymstí nutnou reinstalací celého systému.

[Petr Krčmář]

Ad instalace z dávek: Vydrž do dalšího dílu .

[Rezza]

Ta nevyhoda je naopak u rpm celkem vyhodou, pac zkus prikaz rpmbuild a uvidis jak je to fajn... No pro mne to uz moc neni, vracim se ke slacku:D

[Ales Tosovsky]

Tak zkuste checkinstall. Ten nahrazuje "make install" (nebo i jiné příkazy), vyrobí Vám RPM balíček a ten si nainstalujete. Je to až neuvěřitelně jednoduché.

Domácí stránka: http://checkinstall.izto.org/

Návody:

http://www.root.cz/clanek/2115

http://linux.tosovsky.info/exec.php/show=checkinstall

[Jesus Jimenez]

jj, checkinstall@slackware rulezz ;)

[J]

Je tu moznost, prejit na ciste kompilovany distro. Trebas Gentoo, s poradkem na disku problemy nemam a kdykoli si muzu nainstalovat libovolnou verzi cehokoli. Staci si pridat vlastni "balicek" do portage.

[mirec]

...vcelku fajn, ale tieto problemy s DLL hell tu budu naveky... alebo zeby .NET vyriesilo tieto haluze?

[Re]

NET? To jako projekt Mono? Hahaha, to je přesně to, co pošle GNOME ke dnu. A pak už tu zbudou jen inteligentní KDE technologie a tím dojde i ke standardizaci v oblasti linuxového desktopu. Budoucnost existuje - a začíná na písmeno K. Mimochodem, už J. K. Tyl to věděl - KDE (je) domov můj, KDE (je) domov můj (Doufám, že se to nebude kvalifikovat hanobení státního symbolu...)

[jm]

Kinux se blizi... Diky nechci.

[Jiří Svoboda]

I kdyz uz je tu za posledni tyden ponekolikate flamebait na to same tema, stejne se vyjadrim.
Ano, GNOME se zacina potapet a Mono ho pohrbi. Doufam, ze se to prilis nedotkne Gtk+. Vzhledem k tomu, ze KDE je na <to uz tu tento tyden nekolikrat bylo>, mame obrovske stesti, ze existuji i dalsi, mensi projekty.

[Bender]

Pane orákulum, pokud chcete pronášet radobyosvícené předpovědi, tak si nejdřiv zachatujte s de Icazou. Rád bych věděl čím jsou vaše věštby podložené - četbou diskuzí podobných samožerů, nebo nejakým vaším rozborem?

[Bender]

Pán bude patrně vývojář KDE, když tak vidí do těch inteligentních technologií.

[aaa]

Pán zřejmě nepochopil, že je dnes pátek a že to byl pokus o vtip...

[Bender]

Dobrej pokus.

[Jája Pája]

Chlapi, já Vám vůbec nerozumím!!!!

[jiri.b]

Jeste ze fandim BSD :) Takovy sracky KDE!

[kap]

Mám problem když jsem zadal: ldd /home/mirda/stratagus. Tak mi to napíše ldd není souborem ani složkou. (používám Ubuntu 5.10) PS: Nezlobte se na mě jsem Linux Lama

[Stanislav Brabec]

Asi jste příkaz zadal jinam, než do terminálu.

Toto je příkaz pro příkazový řádek, a ten se zadává v terminálu.

[Stanislav Brabec]

Pokud vám to ale napsalo ldd: /home/mirda/stratagus: není souborem ani adresářem, pak to znamená, že na vašem disku /home/mirda/stratagus neexistuje.

[kap]

Zadaval jsem to v terminalu a ta složka existuje.

[Stanislav Brabec]

Hmm, to je chyba v chybové hlášce glibc.

Parametr pro ldd musí být soubor.

[Stanislav Brabec]

Bug 2415 - ldd: incorrect error message

[Adilkhatri]

검증된 파워볼사이트 를 찾으신다면 eos파워볼사이트 가 있는 파워볼사이트추천 에서 파워볼 을 즐기시길 바랍니다. 5년 이상 운영된 메이저업체 이며 지금까지 많은분들께 사랑받은 안전한파워볼사이트 입니다. 안전한파워볼사이트