LINUX-BG Адрес : http://www.linux-bg.org |
Универсалният изходен код |
От: Nick Angelow Публикувана на: 31-10-2004 Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=365864464 |
УНИВЕРСАЛНИЯТ ИЗХОДЕН
КОД
или защо компилираме програми(те) http://unix.ginras.ru/linux/base012.html Алексей Федорчук
Колкото голяма и всеобхватна да е дистрибуцията на Linux, избрана от крайния потребител, пред него рано или късно изниква задачата за инсталиране на допълнителни пакети или осъвременяване на вече съществуващите. Какви варианти за избор възникват пред него? За потребителя на пакетна дистрибуция от типа на Red Hat (или всяка друга, основана на rpm), натрапващото се решение е намиране на необходимия пакет в прекомпилиран вид и съответен формат (има и съответни услуги от типа на rpm-find, но за съжаление, вече съм ги забравил), след което се изпълнява следната проста команда $ rpm -ihv име_на_пакета.rpm или нещо подобно. След което пакета или се инсталира, или не се инсталира. Ако пакета се инсталира – добре, а ако не се инсталира – има два изхода – да се откажем или да започнем внимателно да изучаваме полученото съобщение за грешка. Да ме извинят привържениците на Red Hat и познавачите на rpm, но това съобщение за грешка, според мен няма да бъде особено разбираемо. По-скоро, смисъла му ще е, че при инсталирането на нашият пакет не е намерен файл от типа име_рек.so.6 или нещо подобно. Интуитивно е ясно, че не е намерена някаква библиотека, но да определим в кой пакет да търсим този файл, от полученото съобщение не е толкова лесно – името на файла в общия случай не съвпада (или корелира по някакъв начин) с името на пакета, в който влиза, тоест вероятността потребителя да се сблъска с проблема за зависимостите и тяхното разрешаване е голяма. И пак, колеги rpm-исти,
не хвърляйте по мен ертефемити1.
Теоретично знам, че съществува стандартен
начин за решаване на този проблем, даже
няколко начина (включително и
най-радикалният – използване на опцията
За избягване на
недоразумения, ще отбележа, че знам за
метода apt, предвиждащ
автоматично получаване на пакетите и
тяхното инсталиране, с осигуряване на
контрол върху зависимостите. Нещо
повече, аз знам, че този метод има шанса
да стане универсален за пакетните
дистрибуции, независимо от формата на
самите пакети. Но при използването на
Някой може да възрази,
че в състава на всеки клон на Red Hat, заедно
с двоичните пакети влизат и пакети с
изходния код на програмата във формат
$ ./configure && make && make install И още нещо – не съм силен в създаването на rpm-пакети, но (imho) надали постигната по последният начин гъвкавост на настройките ще бъде надмината от и най-умело конструираният spec-файл. По друг начин ще постъпи потребителят на някоя source based дистрибуция на Linux или на някоя от версиите на BSD. Във всяка една от тези системи, на негово разположение има цял комплекс за управление на пакетите, известен под името портове (в BSD клонингите или CRUX Linux), portage (в Gentoo Linux), sorcery (в Sorceror Linux и потомците му). Разбира се, и тук изходният код се изтегля от мрежата, а автоматичната система за контрол на зависимостите също е на съвестта на разработчика на порта (portage). Но а) тази система за контрол може да бъде повече (в Gentoo Linux) или по-малко (във всички останали случаи) настроена глобално и б) винаги може да се откажем от автоматичната система за контрол в полза на полуръчното определяне на променливите и опциите на компилация или просто ръчно да конфигурираме всичко. Въпреки всичко, и на потребителя на портирани системи може да се наложи да компилира ръчно най-малкото отделни пакети,например на тези, които все още не са обхванати от системата на портовете на неговата дистрибуция или просто на най-новите версии. А в крайна сметка, гъвкавостта на ръчното компилиране все едно остава ненадмината. Показателни са думите на Андрей Лаврентиев относно FreeBSD – „всеки уважаващ себе си системен администратор, рано или късно прекомпилира със свои настройки всички критични за него пакети“, което на практика означава ръчно компилиране – във порт-системата на FreeBSD няма средства, аналогични на глобалната променлива USE от Gentoo). И тъй като на настолна машина, всеки потребител е и системен администратор, то горното може да се разпространи и върху всеки (уважаващ себе си) потребител. Какво е необходимо на потребителя за компилиране на пакет от изходен код? Първо, това е набора от програми, наричани обикновено инструментариум на разработчика3 (макар,че в случая те да се явяват инструмент за компилиране, ние няма да разглеждаме случаите на внасяне на промени в изходният код, с изключение на най-очевидните). Такива инструменти има във всяка нормална дистрибуция (с изключение на най-специализираните, но пък там те обикновено лесно се добавят). Въпросът е в това. Дали са били инсталирани при първоначалната инсталация или потребителя ги е пропуснал, страхувайки се от тяхната сложност или просто е решил, че са ненужни. По-нататък са необходими
основните системни библиотеки, такива
като И накрая, без да казвам някаква велика мъдрост, ще отбележа, че за компилацията на пакетите от изходен код е необходим самият изходен код. А тук вече започват усложненията. Разбира се, свежият tarball с изходният код лесно може да се изтегли от Мрежата, въпреки, че не винаги това ще е толкова лесно – за такива чудовища като Xfree86, OpenOffice, KDE или GNOME може да се наложи да се изтеглят стотици мегабайтове, което е по силите не на всяка връзка (и не на всеки джоб). Но ще приемем, че това
са трудности на практическата реализация.
Но има и принципно усложнение – това
са тези прословути зависимости на
пакетите. Ако системи от типа А ако започнем да говорим за Xfree86 ... Изпълнявайки в Gentoo Linux командата $ emerge --pretend xfree ние ще намерим в списъка на необходимото и модули за поддържане на планшети wacom, и драйвери за видеокарти 3Dfx, и някакви шрифтови файлове, и много, много други неща, при това независимо от факта дали ние имаме в система графичен планшет, видеокарта 3Dfx и дали имаме наистина нужда от допълнителни шрифтове). Но този дявол не е толкова страшен, колкото го описват. И в ролята на светена вода влиза разбирането на простата истина: зависимостта за зависимостта lupus est4. Казано по друг начин, има пакети, абсолютно необходими за компилирането и работата на дадена програма, има и пакети, които придават на нашата програма само някои допълнителни свойства. Почти във всички описания на зависимости, които съм виждал, разлика между абсолютните (или твърди) зависимости и „опционални“ зависимости (може да ги наречем меки) в явен вид не се прави. Немногобройните изключения са същият този debian.org и документацията на Gentoo.org по работата с portages. Разбира се, на посочените сайтове не трябва да се търси универсални рецепти за всички възможни случаи, но разбирането на принципните разлики между абсолютните и опционалните зависимости много ще помогне – и в двата случая, тези разлики се посочват твърде последователно. Очевидно е, че без
абсолютните зависимости няма да можем
нито да компилираме, нито да стартираме
даден пакет. Всяка програма за Linux изисква
някакви функции от главната системна
библиотека Това са очевидни
примери. Почти толкова ясно е, че
програмите за работа с графика, от
простата Лесно се вижда, че в
ролята на абсолютни зависимости
обикновено се явяват някакви библиотеки.
И основната (и едва ли не единствена)
трудност тук е в съответствието на
версиите. Например, едни от приложенията,
използващи библиотеката Gtk, изискват
непременно нейната втора версия, докато
други приложения се задоволяват с
първата (а с втората, между другото не
могат да се компилират). Но в много
случаи, твърдата зависимост съществува
само за версиите в някакъв интервал
(или казано по друг начин – за даден
пакет е необходима версия на библиотеката
Но без съществуването на абсолютните зависимости, не може да компилираме успешно даден пакет, като е без значение дали връзката му с библиотеката (или някакво приложение) лежи на повърхността или е опосредствена по някакъв друг начин. Ето обаче, че опционалните зависимости, казано строго, не са необходими за компилирането и функционирането на същият този пакет. И макар, че много от тях се определят по подразбиране от разработчиците или компилиращите пакета, е възможно да се отървем от тях, и то по различни начини. Практически всяка
програма под абстрактният Unix, в своя
списък със зависимости ще намери Разбира се, без екранна
документация не е много интересно да
се живее. Но аз практически не използвам
info-страници и затова на моята домашна
самоделна система Но този пример на действие даже не е пила, а по-скоро топор, защото скрипта за конфигуриране е предназначен именно за изключване на опционалните зависимости. И естествено да ги включи, ако се появи такава нужда. Само дето не мога да си спомня някога да ми се е налагало нещо да включвам ... В някои случаи, това
изключване се извършва от самосебе си
– конфигурационния скрипт, изпълнявайки
проверка на системата, намира наличието
или отсъствието на някаква библиотека
и просто игнорира съответната функция
в компилирания пакет. В други случаи,
това се налага да се направи в явен вид
с помощта на опциите Трябва да отбележа,
че премахването на ненужните зависимости
не само води до намаляване на входящия
трафик (и до икономия на място, макар,
че при днешните размери на твърдите
дискове, това не е толкова актуално –
по-важно, според мен, е това, че системата
се освобождава без изключение от
компонентите с неясен произход, които
съществуват във почти всички пакетни
дистрибуции). Води и до повишаване на
удобството на използване при някои
програми. Като пример ще приведа моя
любим И накрая, изключването на ненужните зависимости в някои случаи оказва благотворно влияние и върху бързодействието на програмите. Но тук вече плавно преминаваме от проблемите на зависимостите към въпросите за оптимизация, което вече е друга история. Защото главната
оптимизация се извършва по време на
самата компилация, в хода на изпълнението
на програмата В компилатора CFLAGS="флагове и стойности, разделени с интервал" за програми на С, и променливата CXXFLAGS="$CFLAGS"
за програмите на С++, като не забравяме
да ги експортираме (за любителите на
Трябва да споменем и
това, че може да прекомпилираме и самият
компилатор gcc, което
би ускорило процеса на компилация.
Особено ефективен в това отношение е
така нареченият bootstraping
– прекомпилиране на $ make bootstrap а флаговете за оптимизация се определят от променлива от типа BOOT_CFLAGS="-O3 -march=pentium4" (необходимото да се добави). По съществуващи оценки, това може да доведе до 30% увеличаване на скоростта на компилация, например, на ядрото на системата, което се доближава до истината. Друг начин за увеличаване
на скоростта на компилация (който за
пакети от типа на Xfree86, да не споменаваме
OpenOffice, може да отнеме повече от един час
даже на много мощни машини) може да се
реализира при наличие на голямо количество
оперативна памет. За тази цел е необходимо
да се поддържа виртуалната файлова
система tmpfs, което се задава при
конфигурацията на ядрото и монтирането
и към някаква директория от вида Преценката на увеличаването на бързодействието на компилираните пакети също така е силно субективна, както между другото и оценката на бързодействието на Linux като цяло. Понеже „Linux по подразбиране по определение е глупост (за разлика от „Windows по подразбиране“), потребителя, който не настройва Linux както му харесва, е за другарския съд на Линч, с принудително преминаване към използване на прозорците (© Владимир Игнатов). А какви настройки са оказали най-голямо влияние за крайното бързодействие е много трудно да се определи точно. Малко собствен опит
– след като свърших с тежкия труд по
компилацията на собствена система (по
метода Pure Linux с някои модификации,
комплектоване на пакетите – с големината
на силно олекотен CRUX), аз бях просто
потресен от скоростта на нейната работа.
Но кое се оказа с по-голяма тежест –
дали оптимизацията под Pentium-4 (с посочените
по-горе флагове),
превъзходството на текущия тогава Но аз започнах този разговор не в контекста на самостоятелното изграждане, а с малко по-други цели. Първо, да насоча вниманието на потребителите на пакетни дистрибуции (за потребителите на дистрибуции, основани на изходен код, най-вероятно не съм казал нищо ново) към реалната алтернатива на техните системи за управление на пакети – ръчното компилиране, поне за критично важни приложения. Втората цел е да подчертая, че каквато и дистрибуция на Linux да използвате (или даже каквато и да е BSD система), основата на приложенията в тях е обща. И са породени от движението за свободен софтуер в широкият смисъл на думата. А изхождайки от името е ясно, че всяко едно от тези приложения винаги е достъпно като изходен код, и могат да бъдат компилирани самостоятелно по универсалната за всички тях схема. Като заключение не мога да не изразя своята признателност към Владимир Попов – всичко, изложено по-горе беше окончателно осмислено в процеса на кореспонденцията и личното общуване с него.
превод: Николай Ангелов 1собакит – планинска порода камъни, която се хвърля по кучета, докато ертефемитите (името им произлиза от съкращението RTFM) се хвърлят по нещастните потребители (А.Ф.). 2извинявайте за тавтологията (А.Ф.) 3development tools – така са наречени поне в дистрибуцията Fedora Core 2. 4перифраза на латинската сентенция 'homo hominem lupus est – човек за човека е вълк' 5явно на процеса на компилиране 6за
повече детайли е необходимо да се
обърнем към съответната страница << Slackware и Promise FastTrak 378 RAID контролер | PPPoE и HomeLan настройка >> |
Авторите на сайта, както и техните сътрудници запазват авторските права върху собствените си материали публикувани тук,
но те са copyleft т.е. могат свободно да бъдат копирани и разпространявани с изискването изрично да се упоменава името на автора,
както и да се публикува на видно място, че те са взети от оригиналния им URL-адрес на този сървър (http://www.linux-bg.org). Авторските права на преводните материали принадлежат на техните автори. Ако с публикуването тук на някакъв материал неволно са нарушени нечии права - след констатирането на този факт материалът ще бъде свален.
All trademarks, logos and copyrights mentioned on this site are the property of their respective owners.
|