Установка из исходников: не просто, а очень непросто...
Илья Шпаньков, Knoppix.ru
Это неизбежно, как крах Империализма. Это случается с каждым Линуксоидом. Это подкрадывается незаметно, как бы само собой, мы даже не чувствуем нависшей угрозы, но в один прекрасный момент внутренний голос начинает нашёптывать: а давай установим вот эту новейшую программу? Вы отвечаете: так ещё нет RPM-пакета для нашей системы. А внутренний змей-искуситель не унимается: да ладно тебе, исходники ведь есть! Постепенно ваши возражения по поводу того, что вы этого не умеете, это так сложно, а вдруг что-то испортится, становятся всё неубедительней и в один прекрасный день вы скачиваете из сети архив с исходными кодами ну очень полезной программы. Уже сгорая от нетерпения открываете консоль, вписываете волшебные команды tar xjvf, ./configure, make, make install... Стоп. Не торопитесь: чтобы не плеваться потом на "противный сложный" Linux, давайте попробуем спокойно разобраться, что к чему и зачем.
Изучаем исходные коды
Прежде всего после распаковки архива, что в современных дистрибутивах можно сделать и без применения консоли с помощью соответствующего пункта контекстного меню, устройтесь поудобнее и приготовьтесь изучать содержащиеся в нём файлы. Впрочем, раз уж об этом заикнулся, то напомню. Архивы бывают, как правило, двух типов: tar.gz и tar.bz2. Большой разницы между ними нет, поэтому не будем на этом и заострять внимания. Стандартные команды для распаковки этих архивов выглядят так:
Для архива вида имя_архива.tar.gz:
tar xzvf имя_архива.tar.gz
Для архива вида имя_архива.tar.bz2:
tar xjvf имя_архива.tar.bz2
Итак, у нас имеется каталог, в котором куча всяких непонятных файлов. Но если нет в этом необходимости, то их можно и не просматривать в текстовом редакторе - исходники, как исходники, ничего особенного. Нас интересуют в первую очередь файлы-подсказки, которые научат, как устанавливать данную программу. Вопреки устоявшейся практике, в файле README вы не найдёте ничего существенного - так, ерунда всякая и описание "великих" возможностей данной программы. И совсем другое дело - файл INSTALL: именно в нём можно почерпнуть те крохи информации, которые так нужны начинающим Линуксоидам при первых установках программ из исходников. Но снова огорчу: верить английским словам о том, что, как правило, все программы устанавливаются командами ./configure, make и make install, совсем не стоит. Обычно всё гораздо сложнее. Нет, команды эти правильные и программа скорее всего установится, но вот куда, в какой каталог, в какой конфигурации и будет ли корректно работать - большой вопрос. Но всё по порядку.
Куда ставить-то?!
Это, возможно, один из ключевых вопросов. У разработчиков дистрибутивов существует практика использовать каталог /usr для установки всех пользовательских программ. Поэтому при конфигурировании исходных кодов это нужно учитывать. Чтобы разобраться, куда устанавливать программу, могу дать пару советов из личного опыта.
Когда вы устанавливаете более свежую версию уже существуюущего приложения, то внимательно посмотрите, где расположены его файлы в системных каталогах. Если вы обнаружите папку с названием программы в каталоге /usr/lib, то при конфигурировании исходников нужно использовать соответствующий префикс:
./configure --prefix=/usr
Если не использовать этот параметр, то программа установится в каталог /usr/local/lib. В общем, ничего страшного, и новое приложение даже может работать, но у вас появится две версии программы в системе, что не очень хорошо сказывается на наличии свободного места на диске. Бывают и ещё более изощрённые варианты. Например, в дистрибутиве Mandrake 10.0 очень важный для всей системы пакет Qt установлен в каталог /usr/lib/qt3, и при конфигурировании это нужно явно указывать, иначе все обновлённые библиотеки окажутся не на своих местах, что не позволит другим программам их использовать. Есть способ проверить, куда будет производиться установка новых файлов. Для этого выполните команду ./configure с предположительным префиксом и после окончания конфигурирования зайдите в каталог с исходниками. Возможно, вы увидите файл имя_программы.pc, откройте его и увидите, куда и какие файлы будут установлены:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libgtop
Description: Portable System Access Library
Requires: glib-2.0
Version: 2.5.1
Libs: -L${libdir} -L$(libdir) -L/usr/X11R6/lib -lXau -pthread -Wl,--export-dynamic -lgnome-2 -lpopt -lbonobo-2 -lgconf-2 -lgnomevfs-2 -lbonobo-activation -lORBit-2 -lgobject-2.0 -lgthread-2.0 -lm -lgmodule-2.0 -ldl -lglib-2.0 -lgtop-2.0
Cflags: -I${includedir}/libgtop-2.0
Если данная информация совпадает с теми каталогами, в которые установлены соответствующие файлы предыдущей версии программы, то всё нормально - можете запускать команду make. Если нет - то экспериментируйте дальше. Кстати, можете поискать в системных каталогах и файл имя_программы.pc от уже установленной версии - тогда проблемы с выбором префикса отпадут сами собой. И не забудьте, что если вы ставите целый набор программ, например, 75 файлов графической оболочки Gnome 2.6, то у всех должен быть один и тот же префикс. Бывает, что файл имя_программы.pc отсутствует, тогда не поленитесь, и поищите после конфигурирования в каталоге с исходниками нового приложения другие файлы, которые могут хоть как-то прояснить данную ситуацию.
Раз префикс, два префикс...
Вообще, нужно сказать, что правильное конфигурирование - это 90% гарантий того, что всё скомпилируется нормально и будет стабильно работать в операционной системе. Это единственный этап, где от нас хоть что-то зависит и где можно вносить необходимые поправки, которые помогут собрать действительно надёжную и работоспособную программу. И выполняется эта настройка с помощью уже упоминавшихся выше префиксов. Они представляют из себя дополнительные параметры, которые задаются при конфигурировании программы. Префиксы явно не содействуют упрощению процедуры установки, но являются вынужденной мерой: дистрибутивы Linux имеют некоторые внутренние различия, что и приводит к необходимости более точных указаний для компилятора, каким образом обрабатывать исходные коды. Используются дополнительные префиксы не очень часто, но иногда имеют очень важное значение: неправильно указанный параметр может привести к тому, что программа не будет работать или будет, но с "глюками".
Самое сложное - определиться, какие префиксы нужны. Для начинающего это тёмный лес, в котором не поможет разобраться даже пресловутая бутылка: тут, понимаешь, знания нужны. И внимательность - куда ж без неё. Во-первых, необходимые подсказки часто встречаются в файле INSTALL. Во-вторых, полный список доступных параметров можно просмотреть, задав команду ./configure --help. В-третьих, если конфигурирование происходит не совсем гладко, то компилятор может сам вывести на экран необходимые подсказки и советы. Ну, и в-четвёртых, список необходимых для вашей системы префиксов может находиться и в специальном файле уже установленной предыдущей версии. Например, для Qt в Mandrake я обнаружил файл /usr/lib/qt3/lib/pkgconfig/qt-mt.pc, который выглядел следующим образом:
prefix=/usr/lib/qt3
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
qt_config=qt warn_on release incremental link_prl nocrosscompiler minimal-config small-config medium-config large-config full-config styles tools kernel widgets dialogs iconview workspace network canvas table xml opengl sql release dll thread largefile stl ipv6 system-mng system-jpeg system-png png gif system-zlib nis cups bigcodecs x11sm xshape xinerama xcursor xrandr xrender xftfreetype xkb dylib create_prl link_prl qt warn_on depend_includepath qmake_cache x11 x11inc create_libtool
create_pc moc x11lib
Name: Qt
Description: Libqt-mt.so.3.2.3 Library
Version: 3.2.3
Libs: -L${libdir} -lqt-mt -L/usr/X11R6/lib -L/usr/X11R6/lib -lpng -lz -lGL -lXmu -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread
Cflags: -DQT_SHARED -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -D_REENTRANT -I${includedir}
Сопоставив эту информацию с тем, что показала распечатка ./configure --help, я "сочинил" соответствующую команду для Qt-3.3.2:
./configure --prefix=/usr/lib/qt3 -shared -qt-gif -system-zlib -plugin-style-cde -plugin-style-compact -plugin-style-motif -plugin-style-motifplus -plugin-style-platinum -plugin-style-sgi -plugin-style-windows -no-exceptions -thread -cups -system-libpng -system-libjpeg -system-libmng -no-tablet -release
При этом пришлось дополнительно исследовать и системный каталог /usr/lib/qt3, где в папке с плагинами я и обнаружил, поддержку каких стилей нужно сделать именно в виде плагинов. Но повторюсь, что данный случай - особенный и такая масса дополнительных параметров нужна единичным пакетам. Чаще всего достаточно только указателя на каталог установки. Но и расслабляться не стоит - в жизни всякое бывает. Лучше один раз всё внимательно подготовить, чем потом мучительно "выскребать" из системы файлы, установленные "не туда" и "не так".
Желательно просматривать и весь процесс конфигурирования: бывают случаи, когда компилятор сообщает в процессе подготовки программы к установке, что отсутствует какой-то компонент в системе и данный параметр будет отсутствовать в будущем "новорождённом" приложении. При этом в конце процесса разрешение на дальнейшую компиляцию вы получите. Решайте сами: если отключенные компилятором возможности вам необходимы, потрудитесь предварительно доустановить необходимые библиотеки. В противном случае просто не обращайте внимания и переходите к следующему этапу: компиляции бинарных файлов.
Весёлые картинки
Итак, конфигурирование прошло успешно и мы готовы "делать" из исходных кодов рабочие файлы будущей программы с помощью команды make. Здесь за дело принимается компилятор, установленный в вашей операционной системе: от вас уже ничего не требуется. Можете наблюдать за процессом, можете заниматься своими делами - большого значения это не имеет. Если в процессе компиляции возникнут критические ошибки - процесс будет остановлен с соответствующим сообщением. Более мелкие ошибки могут проходить на первый взгляд незаметно, но будьте готовы к тому, что чем больше таких "нестыковок" будет проскальзывать в тексте компиляции, тем более "глючной" получится программа. Причём, не застрахованы от этого даже так называемые "стабильные" версии программ: полностью без сучка и задоринки прошедшая компиляция - большая редкость.
Скажу сразу, что компиляция - зрелище довольно скучное: на экране монитора с определённой периодичностью сменяются непонятные наборы букв, цифр, палочек-слэшей. Правда, если есть такое желание, то можно отслеживать, в каких каталогах исходников в данный момент происходит компиляция и примерно прикидывать, долго ли ещё всё это будет продолжаться. Но даже если компилируются файлы в последнем по алфавиту каталоге, это ещё не значит, что процесс не вернётся в начальные папки. Как правило, первыми обрабатываются рабочие файлы, потом библиотеки и в самом конце файлы справки. Но и это довольно условно: за время компиляции одни и те же каталоги могут посещаться неоднократно.
Кстати о времени. Срок, за который ваш компьютер "слепит" из исходников готовые файлы, зависит от нескольких факторов: размера программы, мощности процессора и сложности требуемых для компиляции операций. Например, "изготовление" полной библиотеки Qt-3.3.2 с размером исходников чуть больше 60 Мб в распакованном виде, на моём Celeron 466 заняло около 10 часов и превратилось в полновесные 143 Мб! Правда, параллельно я занимался и другими делами на компьютере, что, естественно, забирало на себя часть процессорной мощности. Если же вы планируете обновление покрупнее, вроде графической оболочки Gnome, то запаситесь бутербродами - у меня процесс установки 75 файлов, входящих в полную финальную версию Gnome 2.6, протекал в течении двух дней с небольшими паузами.
Кстати, ещё один немаловажный момент: если вы устанавливаете группу программ, входящих в один пакет, то желательно уточнить, в каком порядке их нужно устанавливать. Как правило, в процессе конфигурирования программы сами сообщают о необходимых для их установки файлах, но и это не показатель. Может случиться и так, что программа скомпилируется без поддержки приложений, которые вы ещё только будете компилировать позднее. К сожалению, в случае с Gnome-2.6 мне не удалось найти соответствующие разъяснения, поэтому пришлось делать всё методом "научного тыка": я выделил, как мне показалось, наиболее важные программы, которые отвечают за всю графическую оболочку и установил их в первую очередь. Далее были установлены обычные приложения и в конце файлы документации. Возможно, я всё-таки что-то упустил, т.к. в процессе работы в Gnome остались некоторые непонятности и "глюки". Что ж, как говорится, идеал недостижим, но к нему надо стремиться. Будем заниматься самообразованием и накапливать опыт. А пока переходим к заключительной фазе - установке скомпилированных файлов в систему.
Инсталлируем и заметаем следы
Здесь от нас опять же ничего не зависит: даём команду make install и ждём результата. После окончания установки новых файлов система сама произведёт переиндксацию, что позволит начать работу с программой без всякой перезагрузки системы. Наша задача - запустить приложение и посмотреть, как всё работает. Если всё нормально - можно считать задачу почти выполненной. Почему "почти"? Я поясню: в связи со страстью к полному порядку в каталогах и ограниченностью свободного места на диске, ситуация, когда установленная на место старой новая версия программы убавляет ровно столько свободного пространства, сколько "весит" сама, меня не устраивает. Логично предполагать, что новые файлы должны заменять старые, но на самом деле это происходит не всегда. В случае с Gnome-2.6 я обнаружил, что новые файлы помещаются рядом со старыми (см. рис 1)!
Возможно, они будут необходимы в том случае, если придётся удалять вновь установленную программу. Но если этого не потребуется, то можете смело избавляться от устаревших файлов - на работоспособность программы и системы в целом это не повлияет. Правда, следует всё же проверить, чтобы одноимённые символические ссылки указывали именно на новый файл.
Есть и ещё один неплохой способ освободить место после установки. Как правило, благодаря напряжённой работе тысяч переводчиков, все программы имеют поддержку нескольких десятков языков. Для каждого случая создаётся отдельный языковой файл и будьте уверены, что после установки новой программы, в систему попадут и все справочные материалы на этих языках. Я почему-то уверен, что никогда не буду работать с узбекским или японским интерфейсом. Спрашивается, на кой ляд мне тогда нужны эти файлы переводов!? Итак, находим каталог, куда установщик положил иностранную "литературу" и удаляем все папки с чужими языковыми файлами. Шутки шутками, но после установки Gnome я "выгреб" из системы почти 60 Мб только справочных материалов и языковых файлов. И это ещё без учёта удалённых парных программных файлов! Конечно, если вы обладаете вместительным жёстким диском, то можете и не тратить время, но личный опыт мне подсказывает, что всё когда-то заканчивается, и свободное пространство на винчестере - не исключение. Вот тогда вы и вспомните добрым словом этот скромный совет.
А напоследок я скажу...
Скажу, что абсолютно не претендую на истину в последней инстанции. Многообразие и гибкость Linux-систем способствует тому, что вариантов работы с ними столько же, сколько и самих пользователей. Не исключено, что кто-то устанавливает программы из исходников и по-другому. Я лишь поделился тем, что знаю сам. И лично моё впечатление такое, что установка из исходников - занятие для истинных фанатов. И ещё меня пугает мысль, что в один прекрасный момент мне придётся переустанавливать систему, что сведёт на "нет" все мои затраты на установку новых программ: весь процесс придётся повторить заново.
Именно эти невесёлые мысли и заставили меня с большей любовью взглянуть в сторону сборки пакетов RPM. Во-первых, и места занимают меньше, во-вторых, их можно легче переустановить при желании. И вообще, готовить из сырых продуктов - оно, может, и вкуснее, но люди всё больше стремятся к полуфабрикатам, которые достаточно только разогреть. Сборка пакетов RPM - дело не очень сложное, но это уже совсем другая история, которая полна своих нюансов, когда, например, сборка не получается по причине нарушения зависимостей, а из исходников программа ставится "на ура"! Впрочем, об этом - в следующий раз...
