Kompilacja i instalacja oprogramowania ze żródeł

Zanim zaczniemy zastanówmy się dlaczego warto cokolwiek ręcznie kompilować. No właśnie - po co? Najczęstsze przyczyny to:

* Brak danego programu/biblioteki repozytorium dystrybucji,

* Chęć lepszego dostosowania oprogramowania do naszych potrzeb,

* Optymalizacja kodu (flagi kompilatora, flagi linkera, stripowanie),

* Chcemy zaingerować w kod programu/biblioteki (łaty, własne modyfikacje)

* Gdy nie mamy dostępu do root'a, a koniecznie musimy zainstalować jakiś program, podczas gdy admin wypoczywa przy szklance soku w Pcimiu Dolnym.

Pierwszym krokiem jest zaopatrzenie się w odpowiednie narzędzia - niezbędny będzie kompilator (gcc), linker (ld, wchodzi w skład binutils), biblioteki (przede wszystkim glibc-devel), automake, autoconf i inne. Skąd mieć pewność, źe mamy wszystko co potrzebne - o tym za chwilę.

Następny krok to zaopatrzenie się w żródła (kod żródłowy) danego programu/biblioteki. W tym celu musimy udać się na stronę danego projektu lub zapytać wujka google'a. Najczęściej występują w postaci archiwum tar skompresowanych gzip'em/bzip'em (*.tar.gz, *.tar.bz2, czasem skracane do *.tgz, *.tbz2). Naukę najlepiej zacząć od niewielkich programów, np. irssi - konsolowego klienta IRC.

W konsoli przechodzimy do katalogu, gdzie zapisaliśmy archiwum (zalecam wypakowywanie do pustego katalogu), następnie rozpakowujemy je poleceniem:


Kod

lub


Kod

Flaga (opcja) 'z' informuje program tar, źe mamy do czynienia z archiwum spakowanym gzipem, a w przypadku 'j' - bzipem. 'x' mówi źe chcemy coś wypakować, 'v' oznacza tryb "gadatliwy" (ang. verbose), a 'f' wskazuje, źe chcemy rozpakować plik, którego nazwa jest dalej. Szczegółowe opisy opcji polecenia tar moźna znależć w man tar

Jeśli w wyniku tego procesu otrzymamy nowy podkatalog - przechodzimy do niego (ok. 85% przypadków).

Na moment zostawię konsolę w spokoju, aby poruszyć kwestię optymalizacji. Informacje o tym jak ustawiać flagi, które z nich są 'bezpieczne', a które nie, moźna znależć w Hoppke Repo. Dodam tylko, źe zauwaźyłem, iź w ostatnim czasie stosowanie flagi -fomit-frame-pointer dla C++ ($CXXFLAGS) przestało powodować problemy (sam uźywam tej flagi, korzystam z gcc serii 4.3).Nawet jeśli ktoś nie ma zamiaru skupiać się na studiowaniu flag kompilatora, to nie zaszkodzi na stałe ustawić popularnych i bezpiecznych flag dla konkretnego modelu procesora. (google -> "Gentoo Safe cflags") Chyba, źe zaleźy nam na przenośności (np. tworzymy paczkę, która ma być dostępna dla kaźdego uźytkownika danej dystrybucji), wtedy najlepiej kompilować pod i686 (pentium pro i nowsze).

Wróćmy do procesu kompilacji. Etapem wstępnym do właściwej kompilacji jest konfiguracja. Odbywa się to poprzez wywołanie skryptu configure z odpowiednimi opcjami. Własnie - jakimi opcjami? Listę dostępnych opcji uzyskamy po wpisaniu:


Kod

Jak widać nowa ściezka będzie miała najwyźszy priorytet (jeśli w systemie jest juź zainstalowany dany program, ale np. jego wersja/konfiguracja nam nie odpowiada, to mamy pewność, źe po wpisaniu samej nazwy polecenia uruchomi się "nasz" program). Aby 'wczytać' nowe ustawienia wydajemy polecenie:


Kod

* Domyślną wartością opcji prefix jest /usr/local. Jak mówi FHS jest to specjalne miejsce na oprogramowanie instalowane lokalnie, wydzielone w celu uniknięcia 'kolizji' plików naleźących do pakietów binarnych (dla których przeznaczono /usr) z 'naszymi' podczas ew. aktualizacji systemu. Nie polecam instalacji z prefixem do /usr, chyba źe wiemy co robimy (np. konfigurujemy źródła z myślą o budowie pakietu binarnego dla naszej ulubionej dystrybucji)

./configure i jego opcje są jedna z największych zalet własnoręcznej kompilacji i systemów typu source-based. Moźemy zdecydowac, z których funkcji programu będziemy korzystać i (co za tym idzie) maja zostać wkompilowane, a które sa z naszego punktu zbędne i chcemy odchudzić z nich program.

Działanie skryptu moźemy podzielic na 2 fazy - sprawdzającą i generującą. Podczas pierwszej sprawdzana jest dostępność niezbędnych bibliotek i narzędzi w systemie, im więcej ficzerów (opcji, funkcji - uźywam tutaj popularnego spolszczenia od ang. 'features') wybierzemy (
Drugą fazą procesu wykonywanego przez [b]./configure jest automatyczne tworzenie plików makefile, które są fundamentem kolejnego etapu, czyli właściwej kompilacji.

Teraz pora na właściwą kompilację - sprowadza się ona w 99% przypadków tylko do jednego polecenia:


Kod

Warto wspomnieć o opcji -jN (gdzie N to liczba procesorów + 1). Definiuje ona maksymalną ilość operacji wykonywanych jednocześnie. Np. dla 4-rdzeniowego procesora będzie to -j5

Jeśli zdefiniowaliśmy własne flagi kompilatora i eksportujemy je globalnie (np. w /etc/profile albo /etc/make.conf) lub lokalnie (np. w ~/.bashrc) wystarczy nam samo polecenie make. W przeciwnym wypadku właśnie w tej chwili moźemy podać nasze flagi kompilatora. Przykład:


Kod

Jeśli otrzymamy komunikat informujący o 'braku celu do wykonania' oznacza to, źe pliki makefile, z których korzysta make nie zostały utworzone. Prawdopodobnie przeoczyliśmy, źe ./configure zakończyło się niepowodzeniem.

Ostatnim krokiem jest instalacja. Słuźy do tego proste polecenie:


Kod

Prosze zwrócić uwagę na znak zachęty - jest to #, poniewaź tę operację wykonujemy z root'a (tzn. wykonujemy ją z poziomu tego uźytkownika, który ma prawo zapisu w katalogu podanym jako prefiks. Jeśli instalujemy oprogramowanie w naszym katalogu domowym, moźemy ten krok wykonać z poziomu zwykłego uźytkownika).

Co prawda mamy moźliwość odinstalowania programu poprzez wywołanie polecenia make uninstall w katalogu, jednak nie jest to najwygodniejsze rozwiązanie poniewaź:

* w przypadku instalacji kilku wersji, z tym samym prefiksem, moźe dojść do usunięcia plików, których nie chcielibyśmy stracić

* musimy trzymać katalog 'roboczy', lub pamiętać jakich opcji/prefiksów uźywaliśmy aby w celu usunięcia programu z systemu wypakować żródła, uruchomić ./configure jeszcze raz, a zaraz po nim make uninstall

Lepsze metody? Tworzenie pakietów! I wcale nie trzeba studiować dokumentacji, a potem wklepywać poleceń jedno po drugim - istnieje automat, zastępujący polecenie make install. Ten automat to checkinstall

Jego uźycie nie powino sprawiać większych problemów, moźna tworzyć zarówno pakiety TGZ (Slackware, Zenwalk i pochodne), DEB (Debian, Ubuntu i pochodne) oraz RPM (Red Hat, CentOS, Fedora Core i pochodne).

Mimo wszystko jeśli chce się zostać developerem "pełną gębą" (dokładniej opiekunem kilku pakietów) jakiejś dystrybucji, załoźyć własne repozytorium, czy 'paczkować' programy z poza repozytorium i umieszczać np. na linuxpackages.net, wypada poznać natywne (klasyczne) metody tworzenia pakietów. Checkinstall jest świetnym narzędziem, ale nie oferuje 100% kontroli nad tym co się dzieje. Jeśli tworzymy pakiety binarne tylko dla siebie, będzie niezastąpiony.

Hwastu

Zaloguj się, aby móc dodawać komentarze.