Portál AbcLinuxu, 19. dubna 2024 18:28

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:

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í:

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:

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.

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é.

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)

Související články

Na co se často ptáme
Kompilovanie jadra

Odkazy a zdroje

GCC home page

Další články z této rubriky

VDR a DVB-T2, část 2.
VDR a DVB-T2, část 1.
Šifrovaný Proxmox VE 6: ZFS, LUKS, systemd_boot a Dropbear
MapTiler – proměňte obrázek v zoomovatelnou mapu
Syncthing

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.