Przejdź do głównej zawartości

HARDCORE - Kompilacja programu pod własny procesor, cz. 1 - qmake

Kompilując program w Arch Linux makepkg wykorzystuje ustawienia w pliku /etc/makepkg.conf. Tam można m.in. wymusić kompilację uwzględniającą określony rodzaj procesora. Innymi słowy, program skompilowany na danej maszynie winien - przynajmniej w teorii - być do niej bardziej dostosowany. Ma to swoje oczywiste konsekwencje. Program tak zbudowany może nie działać na innym komputerze, który ma inny - choćby nieco - procesor. Także po wymianie procesora możemy zostać niemiło zaskoczeni. Niektóre programy nie lubią też takiej, "wymuszonej" kompilacji.
Ustawienia w /etc/makepkg.conf są jednakże ignorowane, gdy program jest prekompilowany z użyciem qmake, bądź cmake. Nie oznacza to, że nie można w tych przypadkach skompilować go z użyciem odpowiednich flag.
W pierwszej części napiszę jak to zrobić dla qmake.
Po pierwsze musimy mieć skrypty umożliwiające budowę paczki dla Archa. Możemy je stworzyć we własnym zakresie, możemy - jeśli program ma zostać przerobiony z dostępnych w repozytoriach, bądź AUR skryptów - skopiować je do dowolnego katalogu. W tym drugim przypadku, używam:
yaourt -G nazwa_programu
albowiem jest mi najwygodniej.
Przechodzimy do katalogu, w którym mamy skrypty i edytujemy PKGBUILD. Bardzo ogólnie ujmując, składa się on z dwu części:

  • pierwszej, w której wprowadzane są pewne deklaracje dla makepkg, gdzie znajdziemy m.in. informacje o tym, skąd skrypt ma pobrać źródła i
  • drugiej, w której umieszczane są instrukcje służące budowie paczki.

Tę drugą dość łatwo rozpoznać, albowiem po jakiś słowie nastąpi seria znaków: "() {". Np.  build() {.
W pierwszej części, np. na jej końcu umieszczamy zatem deklaracje dla kompilatora, które poinformują go o tym, pod jaki procesor chcemy zbudować paczkę. Dodajemy tam dwa wpisy:
CFLAGS="-march=FLAGA1 -mtune=FLAGA2"
CXXFLAGS="-march=FLAGA1 -mtune=FLAGA2"
Oczywiście możemy jeszcze precyzyjniej wskazać jakich opcji ma użyć kompilator.
W miejscu FLAGA1, FLAGA2, wpisujemy flagi właściwe dla naszego procesora, jeśli ich nie znamy, to wskaże je nam polecenie:
gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
Możemy również pójść na pewne skróty, albowiem gcc od wersji 4.2 wprowadził flagę "native". Kompilator sam winien rozpoznać właściwe ustawienia dla naszego procesora i ich użyć. Wówczas powyższe deklaracje przyjmą postać:
CFLAGS="-march=native"
CXXGLAGS="-march=native"
Teraz odszukujemy sekcję rozpoczynającą się od: "build() {". Będzie w niej linia rozpoczynająca się od qmake (lub qmake-qt5) dla aplikacji budowanych z użyciem Qt5 lub qmake-qt4, dla zanikającego już, ale nadal obecnego Qt4. Tutaj, w poleceniach przekazywanych qmake musimy dodać:
CONFIG+=LINUX_INTEGRATED \
        QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
        QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}" 
Sekcja ta może przyjąć zatem następujący wygląd:
build() {
cd build 
qmake PREFIX=/usr \
CONFIG+=LINUX_INTEGRATED \
         QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}" 
make
}
W zasadzie powinno wystarczyć. Wydajemy teraz polecenie:
makepkg -s
(ewentualnie z innymi opcjami) i mamy nadzieję, że tak skompilowany program będzie działał na naszym komputerze lepiej od skompilowanego z użyciem flag generic i jedynie zadeklarowaniem 32 bądź 64 bitowego procesora.
Pozostaje jeszcze to sprawdzić (namcap) i zainstalować wykorzystując
pacman -U nazwa_paczki

Popularne posty z tego bloga

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekaz…