Nebojíme se kompilace - II (praxe)

19. 10. 2004 | Petr Krčmář | Návody | 43599×

Konečně si ukážeme kompilaci v praxi: GCC, configure, make, checkinstall.

V minulém díle našeho miniseriáliu jsme si představili kompilaci teoreticky. Řekli jsme si, o co se vlastně jedná, k čemu je to dobré a dnes si řekneme, jak na to.

Nástroje

Už jsem vysvětlil, že se jedná o plně automatickou činnost řízenou jistými utilitami, které jistě najdete i ve své distribuci. Jde především o:

gcc

gcc je překladač, o kterém jsme mluvili v minulém díle. Provádí samotnou kompilaci, optimalizaci a všechny ostatní důležité operace.

make

Make je velmi důležitou utilitou, která řídí celou kompilaci. Vznikla z potřeby jednoduše zpracovat i velmi rozsáhlé projekty, jejichž ruční kompilace by byla velmi náročná. U větších projektů je potřeba zkompilovat velké množství dílčích souborů, provádět různé úpravy a podobně. Make toto vše dělá automaticky podle souboru nazvaného makefile.

Tento soubor se musí nacházet v adresáři s kompilovaným projektem. Obvykle se vytváří až na místě dle konkrétního systému.

Knihovny

Další důležitou součástí nutnou pro kompilaci jsou takzvané vývojářské knihovny. Ty obsahují hlavičkové soubory nutné pro linkování s konkrétní knihovnou. Od běžné knihovny se obvykle liší přívlastkem dev nebo devel, který je součástí názvu. Knihovna a vývojařská knihovna se tedy mohou jmenovat například:

xlibs-4.1.0 xlibs-dev-4.1.0

Pro běh programu je potřeba mít nainstalovanou jen uživatelskou část, kdežto pro překlad potřebujeme i vývojovou část. Ta ale obvykle není příliš velká, takže se o místo na disku bát nemusíte a není třeba ji po kompilaci odinstalovávat.

Pokud na některou vývojařskou knihovnu zapomenete, překlad neproběhne a poměrně srozumitelně se dozvíme, co je potřeba udělat, abychom chybu napravili.

Zdrojové kódy

Nyní se už dostáváme k samotnému překladu. Před samotným začátkem si neodpustím malou připomínku: Překlad jako takový nemusíte provádět jako root a také to nedoporučuji!

Prvním krokem je samozřejmě stažení souboru obsahujícího samotné kódy překládaného programu. Ten obvykle najdete na domovské stránce konkrétního projektu. Nemůžete-li program najít, obraťte se na Google případně rovnou na Freshmeat.

Stažený soubor (obvykle sbalený tarem a komprimovaný gzipem) rozbalíme pomocí příkazu

tar -xzf nas_zdrojak.tgz

Dalším a často opomíjeným krokem je přečtení dokumentace. Obvykle se v nejvyšším adresáři s kódy nachází soubor INSTALL nebo README. Přečtěte si jej! Obsahuje postup kompilace, která se může od námi probíraného mírně lišit. Obvykle také obsahuje seznam knihoven potřebných ke kompilaci a běhu programu.

configure

Většina kompilací probíhá velmi podobně. Nejprve je potřeba vygenerovat pracovní soubor pro make. Jeho generování probíhá až na cílovém stroji právě proto, aby bylo možno překlad uskutečnit na různých distribucích, platformách a dokonce systémech.

K samotnému vygenerování slouží obvykle skript configure. Ten se nachází v kořenovém adresáři kódů a často pomocí něj můžeme ovlivnit samotnou kompilaci. Volitelně totiž přijímá kompilační parametry, které mění výslednou podobu makefile a tím i konečného programu. Napíšeme tedy

cd nas_zdrojak ./configure --help

a dozvíme se, co a jak, případně jaké parametry můžeme použít. Dejme tomu, že chceme, aby program uměl běhat pod X serverem (a tedy v grafice) a vybrali jsme si parametr --enable-gui. Můžeme tedy zadat

./configure --enable-gui

a skript se spustí. Obvykle je psán v co nejuniverzálnějším jazyce a postupně si ohmatá celý váš systém a pokud najde vše potřebné, vygeneruje zmíněný soubor makefile.

Během práce uvidíte výpis podobný tomuto (zkráceno):

checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking how to run the C++ preprocessor... g++ -E checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include

Pokud se configure u něčeho zastaví a nedoběhne do konce, musíme problém napravit (obvykle chybí některá knihovna nebo utilita).

Kompilace

Jestliže vše proběhlo, můžeme spustit samotnou kompilaci. Make dokáže také přijímat parametry a jedním z nich je název akce, kterou má dle makefile provádět. Pokud neuvedeme parametr, začne defaultní akce, jenž obvykle znamená kompilaci:

make

Opět uvidíme řadu kompilačních výstupů a musíme si počkat. Jak dlouho bude překlad trvat závisí především na velikosti projektu, který zpracováváme, a výkonu našeho procesoru.

Když překlad neskončí hlášením pana Errora, máte vyhráno a právě se vám podařilo přeložit první program. Výsledky kompilace jsou ale ještě stále uloženy v adresáři se zdrojovými kódy. Nyní je musíme dostat do systému.

Instalace

Makefile kromě kompilačního postupu obsahuje také kód pro instalaci programu. Takže stačí ze sebe udělat roota (tentorát už bezpodmínečně) a spustit instalaci:

su Password: ******** make install

Toto je sice nejjednodušší postup, ale má několik nevýhod. Pokud totiž používáme balíčkovací distribuci (což je dnes skoro každá), nebude při tomto postupu balíčkovací systém o nové aplikaci vůbec vědět. To může mít za následek problém se závislostmi (program v systému doopravdy je, ale podle databáze ne). Navíc se připravíme o možnost komfortní odinstalace a v systému nám tak začne postupem času vznikat nepořádek. Řešením je vytvořit před instalací balíček a ten následně nainstalovat.

Opět to nebude nic těžkého a postačí nám k tomu utilita checkinstall, která dokáže sledovat činnost make install, rekonstruovat všechny kroky, posbírat soubory a sestavit balíček.

Místo posledního příkazu tedy použijeme

su Password: ******** checkinstall

Program se po krátké přípravě zeptá, pro jakou distribuci má balíček vytvořit (Slackware, RPM nebo Debian), vyžádá si popis programu a po kontrole údajů se již balíček vytvoří a nainstaluje.

Hotovo. Tímto jste zkompilovali a nainstalovali svůj první program.

"Zavuete očíčka pane Čupeuo, tááák. A teď otevuete ... že to nebolelo?" (J. Werich: Až opadá listí z dubu)

Příště se podíváme na nějaké vychytávky a ukážeme si, jak kompilaci vylepšit.

       

Komentáře

[Eagle]

... má parametr -c, man su.

[Jarek Šeděnka]

checkinstall už funguje pod jádrem 2.6? nedávno jsem kvůli tomu narazil...

[Antonín Kolísek]

Checkinstall vždycky fungoval pod jádrem 2.6. Alespoň jej tam sám provozuji od dob co 2.6 jádro existuje.

[slesik]

když nefunguje normální checkinstall (fedora, mdk), tak instaluju již upravený chekc... ze suse .. ftp://ftp.sh.cvut.cz/SuSE/i386/9.1/suse/i586/checkinstall-1.6.0beta3-8.i586.rpm

[svaca]

Checkinstall nebezi dohromady s knihovnou libsafe .... Paklize mate oboji, je problem ...

[Greenhorn]

Tímto chci poděkovat tvůrci za článek o kompilaci. Jsem začátečník, linux se mi velice líbí. Uvedený proces jsem již dělal párkrát. Bohužel jsem vlastně nevěděl, co dělám. Nyní, díky teorii a rozboru jednotlivých procesů mám jasno. Hlavně je to napsané velice srozumitelně i pro mne, co by "zelenáče". Budu čekat na další pokračování. Díky za to !!

Pavel

[Petr Krčmář]

Ahoj, díky za díky . Právě proto jsem samozřejmě články psal -- aby pomohli začátečníkům překonat strach. Není to tak hrozné.

Petr

[johncross]

Dobry den,

cetl jsem si vas prispevek...je zajimavy. Ale vy se v nem venujete pouze verzi kde pracujete s configure souborem.

Co kdyz jsem si stahnul rpm bez konfigure? Jak mam postupovat potom?

Dekuji

[Stanislav Brabec]

Chtělo by to poznamenat, že checkinstall sice vytvoří balíček rychle, ale nejde o korektní cestu k balíčku.

Za určitých okolností totiž může balíček vytvořený checkinstall poškodit systém:

Některé programy provádějí další akce k zaregistrování programu. Nejběžnější ldconfig checkinstall nezmate, ale takový gst-register, gconftool-2 a další již mohou. V nejhorším případě může použití useradd vložit do balíčku /etc/passwd, a při odstranění takového balíčku je zaděláno na velký problém, neboť v některých distribucích soubor /etc/passwd nevlastní žádný balíček, takže jej balíčkovací systém odstraní.

Korektní práce na balíčku začíná (u balíků korektně napsaných s pomocí automake) s "make DESTDIR=moje_pomocná_cesta install", které se nespouští pod rootem. V Debianu a Gentoo existují utility, které přitom korektně detekují chown a chgrp. Pak následuje prohlídka seznamu souborů a tvorba balíčku.

[finn]

Před samotným začátkem si neodpustím malou připomínku: Překlad jako takový nemusíte provádět jako root a také to nedoporučuji!

Já si také neodpustím malou připomínku: když už je napsáno, že se něco má/nemá udělat, mělo by také hned následovat vysvětlení proč, jinak je informace neúplná a téměř nicneříkající.

[Robert Krátký]

Tu svoji připomínku jsi však mohl doplnit tím vysvětlením, které v článku postrádáš.

Co se kompilace jako root týče, neexistuje nějaký speciální důvod, proč to nedělat. Respektive, ten důvod je stejný jako u spousty dalších běžných činností. Stejně tak jako není potřeba být root k prohlížení webu, přehrávání písniček nebo psaní dopisů, tak to není nutné při kompilaci.

Nedoporučuje se to z podobných důvodů, jako se nedoporučuje provádět výše zmíněné činnosti jako root: je to bezpečnostní riziko. Přičemž největším nebezpečím je uživatel sám sobě, protože jako root může bezděky napáchat v systému škodu, kterou se nemusí podařit napravit. Jako běžný uživatel na podobně destruktivní činnost nemá právo, a proto je to tak bezpečnější.

[pasmen]

To je sice pravda, ale: kdyz se clovek treba snazi vytvorit balicek, kompilovat to jako user a nasledne menit vlastnika a prava zpet na roota apod. je dost otrava. Pokud balicek nevytvari a pousti rovnou make install, coz dela prirozene jako root, je to mnohem vetsi riziko nez kompilace. Leda ze by nekdo totalne po*** Makefile... )

[Robert Krátký]

a nasledne menit vlastnika a prava zpet na roota apod.

Proč?

[pasmen]

Neni to nutnost, ale nektere adresare dodrzuji urcita pravidla, jako ze /bin atd. maji vlastnika a skupinu root.bin apod. Pokud program zkompilujete jako normalni user, musite ty skupiny a vlastnika zmenit.

[Eagle]

Taky mi občas připadá, že to někdo s paranoiou přehání. Pokud nedokáže kontrolovat svou činnost, neměl by spravovat server. To je asi jako kdyby při odhlašování z produkčního windows serveru kliknul omylem na shutdown místo log off . Stát se to může, ale je ten člověk na správném místě?

[Robert Krátký]

To je dost postavené na hlavu. Nerespektovat určité jednoduché zásady bezpečnosti jen proto, že si člověk myslí, že už je velký kluk a má na to, to je zvláštní důvod. Když je někdo hasič, ještě to neznamená, že se mu nic nestane, když škrtne sirkou na benzínce...

[Zdenek Kaminski]

Takze predpokladam, ze procitate Makefile, aby jste vedel, co dela prikaz 'make install' a ze si jste skutecne jisty, ze Vam nic nepreplacne, nesmaze...

Ono totiz i tvurci Makefile obcas udelaji botu a prikaz rm ci install nemusi mit vzdy tu spravnou volbu. Az se jednou spalite, tak uz pod rootem delat nebudete...

[svaca]

Ja tedy nevim, Slacka pouzivam od 7 verze a vse si kompiluju sam (pouzivam checkinstall), nepouzivam swaret, atd ... a uz balicek rozbaluju jako root ... a NIKDY jsem nemel problem, maximalne nekdy cheinstall byl nekompatibilni s Makefile a NENAINSTLOVAL vubec nic, jinak zadny problem ...

[Robert Krátký]

Už tak dlouho chodím se džbánem pro vodu, a ještě NIKDY se mi ucho neutrhlo...

[pasmen]

Presne tak, pokud se bojite make tak z make install musite kleknout... Protoze, pokud na Vas nikdo nechysta past, tak se kompilaci "nemuze" nic skazit, vzhledem k tomu ze to zatim nehrabe do systemu (narozdil od installu). A to nesouvisi s tim , jestli je nekdo uz velky kluk nebo ne

[Michal Marek (twofish)]

Ona ta kompilace bohužel někdy nespočívá jen v ./configure && make, ale občas i vim soubor/ve/kterem/to/buhvi/proc/hlasi/chybu.c a vim co/zas/za/chybu/je/v/tom/Makefile nebo vim ktery/prase/psalo/ten/configure.in, a tolik věcí dělat pod rootem už opravdu není dobrý nápad (nehledě na to, že chci používat to nastavení programů, na které jsem zvyklý a které mám v $HOME)

[Jiří Svoboda]

Jen doplneni k diskusi vyse.
Neni to tak davno, kdy se nekomu (v souvislosti s nejakym hackem) podarilo propasovat do konfiguracnich scriptu jedne aplikace jiste zmeny. Ve vysledku to znamenalo, ze pokud nekdo spustil './configure' jako root, byl stroj kompromitovan. Samotna aplikace byla beze zmen a tudiz nepostizena.
Dalsi duvod, proc './configure' a 'make' urcite nespoustet jako root.

[Kokes]

Zdar jsem celkem zacatecnik (o cemz svedci i distribuce), pri pouziti checkinstall to hodi hlasku, ze rpm build failed. Nestalo se to nekomu? Ze bych po tom nemusel patrat... Predem dik za cokoli

[Dano]

Chcel by som sa spytat co v pripade, ze som bol sikovny a pokompiloval som nejake veci bez checkinstall. Da sa to dostat dodatocne do db, alebo musim rekompilovat?

[Michal]

Je to vyvetlene celkem hezky, ale chtelo by to se zminit, ze nekdy se stava, ze mame nejaky nainstalovany program nebo knihovnu, ale pri ./configure se ten program nenajde a hlasi to chybu, ze ho nemuze najit. Jak se to resi?

[Stanislav Brabec]

Překvapivě přesně tak, jak configure radí:

See config.log for details.

Důvodů selhání je mnoho:

- chybí devel balíček

- knihovna je jinde

- závislá knihovna je jinde

- knihovna závisí na další nepředpokládané knihovně

- nevhodná verze knihovny

- kompilace testovacího programu selhal

- chybí potřebný include soubor

- test není dostatečně obecný

atd.

[Greenhorn]

Včera jsem si zkusil vytvořit zkušebně rpm balíček pomocí checkinstall. Bohužel se mi to nepovedlo. ./configure i make proběhli bez errors až do konce. Když jsem dal příkaz checkinstall, program naběhl a po chvíli se mě zeptal, zda chci vytvořit nějaký adresář ./doc. Defaultně tam bylo v hranaté závorce yes, tak jsem jen potvrdil. Bohužel to následně vypsalo několik chybových hlášení a že nelze najít adresáře a soubory. Program nahlásil, že make install nebyl proveden a bye. Po druhé se to již na nic neptalo a výsledek byl stejný. Tak jsem zadal tedy klasicky make install a vše proběhlo O.K.. Ale co se chci zeptat. Je rozdíl mezi instalací RPM nebo klasickou kompilací source dat v ukládání souborů? V adresářové struktuře linuxu je několik adresářů bin, lib a pod. Mám za to, že pokud instaluji rpm, soubory se uloží do jiných adresářů, než když provádím kompilaci ze zdrojových kódů. Dá se to nějakým způsobem sjednotit, nebo je to zbytečné? Distro mám MDK 10.0. Kernel řady 2.6.x

[Stanislav Brabec]

Je to standard daný FHS. Programy spravované balíčkovacím systémem patří do /usr (pokud jsou nutný pro počáteční boot, pak do /), programy instalované ručně do /usr/local (implicitní hodnota configure skriptu), programy třetích stran do /opt/vendor_prefix.

[Greenhorn]

Díky moc za odpověď. Proč jsem se ptal. Dám příklad. Stáhnu si někde RPM balíček s programem. Dám ho instalovat. Zahlásí chybějící závislost na nějaké knihovně. Tu už neseženu jako RPM balíček, jen jako soubor knihovna.tar.gz k ruční instalaci. Proto mne zajímalo, zda tomu RPM balíčku při instalaci je to jedno a při hledání závislé knihovny hledá i v jiných adresářích (/usr/lib nebo /usr/local/lib a tak). Bohužel mám jenom jeden počítač, na kterém mi linux běhá velmi dobře. Nerad bych si ten systém pokazil nějakým hloupým zásahem, proto se radši poptám chytřejších a zkušenějších. Díky.

[Stanislav Brabec]

RPM knihovny vůbec nehledá. Jména knihoven jsou pro něj abstraktní symboly jako každé jiné v seznamu závislostí, který je vytvářen při sestavování balíku (rpmbuild). Jeden RPM je dodá (--provides), druhý je vyžaduje (--requires). Sbírání symbolů z knihoven, binárek a skriptů při sestavování RPM se ve spec souboru jmenuje AutoReqProv.

[ion_cannon]

Ahojte, potreboval by som poradit, zakazdym ked spustim ./configure proces mi skonci hlaskou ¨error: no acceptable C compiler found in $PATH See `config.log' for more details.¨ Neviem velmi po anglicky a ked som sa pozeral do suboru config.log velmi som tomu nerozumel, som este uplny zaciatocnik a neviem si rady. Predpokladam ze budem musiet nieco doinstalovat, no neviem co. Vopred dakujem za radu PS: neviem ci je to potrebne ale pre istotu uvadzam ze pouzivam Mandrake 10.1 jadro 2.6.8.1

[Stanislav Brabec]

Potřebujete "C compiler" (C kompilátor), tedy např. gcc. Alespoň základy angličtiny jsou pro kompilaci nutné.

[ion_cannon]

No pozeral som cez rpmdrake ci to tam nahodou nie je no a vyhodilo mi ze gcc nainstalovane mam a to vo verzii 3.4.1-3mdk hmm co teraz?

[Stanislav Brabec]

Pak tedy: See `config.log' for more details. (Podrobnosti viz `config.log'.)

Tam bude popsaná chyba, proč configure nevidí kompilátor. Možná vám chybí vývojářské balíčky (-devel), např. glibc-devel apod. (může se lišit podle distribuce; budete jich většinou potřebovat desítky). Více viz článek.

[ssil]

Chybu vidím v tom, že to co kompiluješ potřebuje jinou verzi gcc než máš. Na to stačí odkaz

ln -s /usr/bin/gcc-[máš] /usr/bin/gcc-[požadované]

Alespoň mě to v Debianu funguje. Ještě připomínku. Jsem taky začátečník a zbytečně jsem ztrácel čas pochopením nutnosti mezer tak jak jsem napsal.

[ssil]

Chybu vidím v tom, že to co kompiluješ potřebuje jinou verzi gcc než máš. Na to stačí odkaz

ln -s /usr/bin/gcc-[máš] /usr/bin/gcc-[požadované]

Alespoň mě to v Debianu funguje. Ještě připomínku. Jsem taky začátečník a zbytečně jsem ztrácel čas pochopením nutnosti mezer tak jak jsem napsal.

[Greenhorn]

Dobrý den všem linuxovím odborníkům! Mám malý problém. Zkoušel jsem si vytvořit rpm balíček pomocí programu checkinstall. Mám distribuci Mandrake 10.0. Instalace ./configure a make proběhne v pořádku. Pak dle návodu v článku spustím na místo make install příkaz checkinstall. Program se spustí ,něco si to přečte, začne pracovat, ale po chvíli program ukončí svou činnost a s rozloučením "bye" se zastaví. Něco se mu nelíbilo a to něco je jakýsi časový posuv nebo časové zpoždění, s tím, že nemůže najít adresáře nebo soubory. Zkoušel jsem program spouštět s různými parametry, ale nekápl jsem na to pravé. Nemáte s tím někdo nějakou zkušenost? Díky za odpověď.

[johncross]

Dobry den, cetl jsem si vas prispevek...je zajimavy. Ale vy se v nem venujete pouze verzi kde pracujete s configure souborem.

Co kdyz jsem si stahnul rpm bez konfigure? Jak mam postupovat potom?

Dekuji

[Fox]

Huráá konečně jsen našel co jsem potřeboval.

A je to napsané celkem blbovzorně.

Děkuju

[wasil]

No já mám problém že configure mi vůbec nejde...mám Mandrake 10.0???

[vencour]

Další zajímavé postupy, díky Tomovi: odkaz do diskuse.

[Tomas]

Na uvod -pouzivam mandrivu 2007 a jsem zacatecnik...ted k problemu...navod se mi velmi libi muj pokus o zkompilovani probehl uspesne,ale zkompiloval sem si napriklad kaffeine a bohuzel nevim jak ho po nainstalovani spustit...po nainstalovani z bezneho rpm balicku stazeneho ze stranek projektu staci pote vytvorit spouteci soubor a do cesty zadat "kaffeine" a program se spusti...po instalaci z meho rpm balicko to nefunguje....diky za radu,vim ze nejspis jen musim zadat spravnou cestu,ale nepodarilo se mi ji najit

[robinek]

no ja mam problem ze pri kompilaci jisteho programu Google gadgest se mi po zadani ./configure zastavila priprava na teto chybe: configure:3740: error: C compiler cannot create executables. Ze by chyba v GCC ? jinak config.log je tu: http://disk.jabbim.cz/robinek@jabbim.cz/config.log , moc jsem z nej chytry nebyl

[Stanislav Brabec]

Viz druhý odstavec. Nemáte nainstalované vývojářské balíčky. Tentokrát vám chybí zřejmě glibc-devel (záleží na konkrétní distribuci).

[robinek]

tak jsem doinstaloval vyvojarske nastroje a porad stejny error. ani nevim kde je v logu napsano co tomu chzbi nic jsem nenasel .

[Stanislav Brabec]

Hlavním problémem je toto:

/usr/bin/ld: crt1.o: No such file: No such file or directory

Kompilátor nenašel soubor crt1.o, který se na většině 32bitových systémů nachází v adresáři /usr/lib a např. v openSUSE je součásti balíku glibc-devel. Jak je to ve vaší distribuci, netuším, ani nevím, která to je, neboť se hlásí jen jako i686-pc-linux-gnulibc1 (nicméně argumentem configure bylo i486-linux-gnu).

[Pev]

Ještě stojí za zmínku, že pro kódy získané pomocí gitu se většinou pouští autogen.sh.