Наши партнеры

UnixForum
Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

На главную -> MyLDP -> Тематический каталог -> Установка новых программных пакетов

Три шага до любви к Свободному софту: configure, make, make install

Оригинал: "How to love Free Software in 3 steps: configure, make, make install"
Автор: Mitch Meyran
Дата: 8 марта 2008
Свободный перевод: Алексей Дмитриев
Дата перевода: 15 апреля 2008

Недавно я перечитал статью Стивена Гудвина "How to hate free software in 3 easy steps" (перевод на русский язык сделан А.Дмитриевым: "Три шага до ненависти к свободному ПО"). Не будучи программистом, я тем не менее, самостоятельно установил несколько дистрибутивов. И, честно говоря, у меня есть претензии к этой статье.

К данной статье также были комментарии, в которых утверждалось, будто не-программисты не собирают программы из исходного кода, будто сама сборка из исходников требует квалификации программиста, и что другие операционные системы не "падают", когда вы "химичите" с их разделами.

Вы позволите?

Химичим с основными системными файлами, аптечка первой помощи

Возьмем обычный пример: вы полностью нарушили базовую систему DLL в Windows XP. Удивительно, но ОС еще работает. Объяснение: система динамически заменяет испорченные/удаленные базовые файлы из потайного резервного кэша. Эта система существовала уже в Windows 2000, но в XP она включает большинство базовых инсталляционных файлов (включая Messenger). Однако попытайтесь удалить все копии файла, который вы хотите модифицировать, все одновременно, откажитесь восстанавливать файл с CD и вы сможете увидеть, как система рушится и сгорает.

На деле, как пользователь Джо, вы не сможете разрушить систему, потому что вам активно не позволяют химичить с ней, и система автоматически восстанавливает все, что вы пытаетесь в ней изменить, пока она работает. Более того, тот факт, что Windows "запирает" открытые файлы, сильно затрудняет попытки "убить" систему до перезагрузки (по крайней мере, в этом частном случае).

Под GNU/Linux и xBSD: если вы модернизируете системный файл, то создавайте его резервные копии. Также полезно изучить, из чего состоит минимальная загружаемая система. К этому стоит добавить, что никакая сила не сможет помешать вам восстановить систему с загрузочного CD, если вы сделали резервные копии модифицированных вами файлов, так как не существует никакого "регистра" с контрольными суммами измененных файлов, могущего помешать вам восстановить резервные копии. Последнее по счету, но не по значению: большинство пакетных менеджеров позволяют вам переустановить пакет с восстановлением всех настроек по умолчанию.

И наконец, версии библиотек UNIX-подобных систем весьма развиты: вы не только можете иметь несколько версий библиотеки, мягкие ссылки и правила для динамической линковки позволяют вам создавать специальную версию библиотеки, которая будет "обслуживать" единственную программу, безо всякого ущерба для остальных. Короче, у вас мало шансов превратить Линукс систему в невосстановимый хлам, даже "химича" с системными файлами, кроме того случая, когда вы являетесь системным администратором, вооруженным молотком и соответствующими навыками.

Что касается повреждения жесткого диска, то это вина не GNU или BSD и даже (обычно) не Windows.

Химичим с разделами жесткого диска, основные ловушки

Существуют три основных причины повреждения разделов GNU/Linux:

  1. Устаревшие сведения, записанные в менеджере загрузок (LILO или GRUB); обычно случается, когда обновляют ядро, и забывают обновить GRUB или LILO.

  2. Неправильная нумерация разделов; обычно происходит при удалении, перемещении, или изменении размеров разделов при сложном разбиении диска.

  3. Перезаписана Главная Загрузочная Запись (Master Boot Record); обычно следствие установки Windows XP или Vista (Windows 2000 ведет себя более порядочно).

Ловушки многообразны, иногда остается только удивляться. Однако, по крайней мере с GNU/Linux еще можно надеяться на восстановление, тогда как с ОС типа Windows чаще всего приходится прибегать к переустановке (у меня был случай, когда клонированный раздел настаивал, чтобы после реставрации его величали 'F:', никаких способов загрузить такую систему не было и все папки реестра были повреждены).

    Прим.перев.: папка - раздел реестра, представляет собой набор ключей, подключей и значений, который находится на верху иерархии реестра; папки можно перемещать из одной системы в другую и редактировать с помощью редактора реестра.

Первой проблемы легко избежать: не удаляйте старое ядро, до тех пор, пока не убедитесь, что новое работает. И всегда обновляйте LILO или GRUB после любых действий c ядром.

Во втором случае, когда вы начинаете изменять размеры, уничтожать и создавать разделы по всему диску, запаситесь эффективным LiveCD (Knoppix очень рекомендуется), не только потому, что это хороший инструмент для восстановления, просто лучше не работать сразу с "живой" системой (не потому, что это невозможно, просто это избавит вас от "жонглирования" командой chroot все время). Кроме того, это позволит вам возвратиться к исходному состоянию и/или обновить вашу /etc/fstab в течение пары минут. Больше того, при редактировании этого файла, у вас есть ряд опций.

Существует два способа адресоваться к периферийным устройствам в файле /etc/fstab для их монтирования: вы либо можете вызывать их через /dev (например, /dev/sda1), либо вы используете UUID (Универсальный Уникальный Идентификатор) - последние гораздо труднее писать "из головы", но зато делает подключение к GNU/Linux системе гораздо проще. Больше того, в этом случае гораздо меньше шансов стать жертвой перепланирования разделов, как при использовании метода с путями /dev.

Падение ядра

Некоторые дистрибутивы позволяют большую свободу настроек ядра, чем другие. Например Mandriva позволяет собирать ядра из "ванильных" исходников, используя всего несколько командных строк в консоли, тогда как Ubuntu относится к этому весьма болезненно, так как не умеет автоматически создавать образ RAMdisk'а, в котором содержатся модули, необходимые для загрузки. Можно найти массу полезной информации на форумах вашего дистрибутива (кстати посты с форума одного дистрибутива могут быть полезны для другого; форум Gentoo - настоящая золотая жила в том, что касается повышения скорости компиляции,).

Когда дело касается подключения модулей ядра, прежде чем вы сделаете что-либо действительно глупое, система даст вам достаточно предупреждений, чтобы предотвратить крах системы.

  • Если модуль не поставляется вместе с "ванильным" ядром, он может работать не очень стабильно.

  • Если модуль не поставляется вместе с "дистрибутивным" ядром, скорее всего, он крайне нестабильный.

  • Если команда dmesg выдает версию ядра, не совпадающую с загруженным модулем, он может вообще не работать.

  • Если команда dmesg выдает рассогласованные символы, то вы пытаетесь вставить квадратный штырь в круглое отверстие.

Если после всего этого вы настаиваете на загрузке данного модуля и форсируете этот процесс, то молитесь. Просто молитесь. Горячо.

Компиляция: когда стоит ею заниматься

Существует 3 случая, когда вы можете захотеть скомпилировать программу из исходного кода:

  1. Программа вам нужна, а в вашем дистрибутиве она отсутстыует (а проверили ли вы все доступные источники? Альтернативные репозитории?)

  2. Предлагаемая версия старая, глючная, либо медленная.

  3. Предлагаемая версия скомпилирована не с теми опциями, которые вам нужны.

По пункту 1. Можно попробовать взять пакет из другого дистрибутива - программы alien и smart позволяют даже устанавливать Debian пакеты на Red Hat и наоборот, так в чем же дело? Разве что вы точно знаете, что пакет легко компилируется (но тогда вы бы не читали этих строк, а давно уже все установили).

По пункту 2. В общем, то же, что и по первому пункту. Если желаете играть с огнем, примите меры против пожара: резервные копии, бэкапы, бэкапы... Несомненно правильно установленное из исходников ядро может придать вашей машине ощутимое преимущество в скорости (отключение поддержки мультипроцессорности на однопроцессорной системе, компиляция с экзотическими опциями процессора, вместо "родных" i586 для 32-битных систем, отключение всех опций отладки - это еще можно попробовать; все остальное не стоит труда).

По пункту 3. Вы можете поискать пакет с исходными кодами для вашего дистрибутива, он будет снабжен оригинальными инструкциями, и по крайней мере, вы можете быть уверены, что уже установленный софт не пострадает.

Короче: а так ли вам необходимо устанавливать из исходников?

Компиляция 2: что стоит делать, и чего не стоит.

Для начала, RTFM, то есть прочтите мануал! Это может быть README или INSTALL файл, поставляемый с большинством пакетов исходного кода. Если пакет не снабжен конфигурационным файлом configure, то у вас два варианта:
  • либо тарбалл содержит экспериментальный снимок программного обеспечения, и вам придется создать makefile самостоятельно, пользуясь программами automake или cmake; прочтите инструкции, чтобы выяснить, что требуется и рекомендуется для вашей системы!
  • либо тарбалл не подразумевает makefile вообще (файлы исходного кода проводят проверку сами, либо система сборки является встроенной, не нуждаясь в конфигурационном скрипте), в этом случае переходите сразу к стадии make.

Если вы не смогли найти никаких инструкций по сборке, попробуйте сразу запустить make. Если это не сработает, программа make сообщит вам, чего не хватает. Вернитесь к началу, намыльте, промойте, повторите.

Начало конфигурирования

Как уже сказано раньше, скорее всего вы найдете внутри тарболла инструкции, в той или иной форме. Если есть конфигурационный скрипт, но нет мануала, попробуйте запустить ./configure --help, чтобы получить список опций. Применяйте те, что вам нужны (например многие программисты размещают скомпилированные бинарники в директорию /usr/local, но в некоторых дистрибутивах вы захотите поместить результат в директорию /usr), и начать работать.

Например, ./configure --prefix=/usr заставит систему поместить все в "главную" системныю директорию. Это не рекомендуется для первичной компиляции, лучше поместить все это куда-нибудь в другое место (скажем, /usr/test, или вроде того), а позже, при помощи мягких ссылок вы сможете использовать их вместо ранее установленных библиотек.

Когда скрипт будет работать, внимательно смотрите за выходом - даже самый ненастроенный скрипт скажет вам, чего он ищет. Когда процесс закончится, постарайтесь установить столько недостающих пакетов (как библиотек, так и инструментов разработки), сколько сочтете нужным, а затем запустите ./configure снова. И снова пристально изучайте выход. Некоторые программы более "разговорчивы", чем другие, и в конце концов вы убедитесь, что не упускаете чего-то важного с самого начала.

Теперь настала пора команды make - внимательно изучайте выводы, так как прерванная компиляция часто комментируется сообщением типа "line XXX: undeclared variable #something". Если вы получите несколько таких сообщений, это обычно означает отсутствующую библиотеку, не включенную в ./configure (если это действительно так, то хорошо бы проинформировать об этом разработчика); установите библиотеку с названием как можно более похожим на название отсутствующей переменной, и попробуйте снова. Должно сработать.

Намыльте, промойте, повторите. В конечном итоге вы получите собранный пакет. Остальное сделает make install (не забудьте про приставку (--prefix=/usr/test), которую вы установили на стадии ./configure), я бы не советовал убирать ее сразу, сначала проверьте, как работает локальный исполняемый файл. Больше того, посмотрите какие файлы могут быть заменены; если возможно, деинсталлируйте вначале конфликтующие пакеты.

Компиляция закончена, что дальше?

Теперь, когда вы достигли этой стадии, вы продвинулись так же далеко, как Билл Гейтс, когда выпускал Windows 95 ("она скомпилировалась! Скорее, отправляйте"). Следующим шагом будет использование новой системной библиотеки. Если вы последовали моему совету, но не смогли удалить пакет (слишком много зависимостей), то теперь у вас работает старая библиотека, а вновь созданная не используется. Переходите в директорию, куда собираетесь поместить файл. Переименуйте старый файл (mv libthingie.so libthingie.so.old) и создайте симлинк к новому файлу (ln -s /usr/test/lib/libthingie.so .), запустите ldconfig и (пере)запустите программу, которая использует эту библиотеку. Если все работает, перезапустите остальные процессы. Если все рушится, отмените все, что сделали, восстановите старую библиотеку (rm libthingie.so && mv libthingie.so.old libthingie.so) и проверьте еще раз, что скомпилировали вышу библиотеку корректно (будьте внимательны с 32/64-битами, "упавший" процесс будет жаловаться на несовпадение символа).

Если вы собрались построить модуль ядра (скажем, крайне нестабильный mach64 DRM модуль), то поможет следующее руководство: все, что нужно сделать, это распаковать git extract, запустить make, затем вручную скопировать файлы drm.ko и mach64.ko в ваше дерево ядра. Только не забудьте сделать резервную копию "родного" drm.ko (или drm.ko.gz) где-нибудь в надежном месте и запустить программу depmod -a после копирования. Можете сжать их при помощи gzip, если хотите. Затем попробуйте modprobe mach64 и посмотрите вывод команды dmesg | tail, чтобы убедиться в отсутствии ошибок.

Сразу после этого вы можете перезапускать Xorg и посмотреть заработает ли DRI (Direct Rendering Infrastructure): на некоторых системах он запустит Xorg и GNOME, KDE или Xfce вполне нормально, до тех пор пока вы не начнете настраивать фон; в других случаях появится черный экран, а иногда и "мертвое" зависание системы, так что неплохо заране поставить в файле /etc/inittab initial init level в значение 3 (Mandriva, SuSE) или 1 (Ubuntu), или иметь где-нибудь запасной образ ядра.

Заключение

У меня нет квалификации программиста, честно говоря, я в жизни не написал ни строчки на C/C++. Тем не менее, я успешно собрал несколько пакетов из исходников, не забывая несколько простых правил:

  • Читайте руководства
  • Снова перечитайте руководства, так как некоторые места вначале станут более понятными.
  • Читайте файлы релиза, они иногда противоречат руководству, и вы будете знать, чего ожидать.
  • Проверяйте опции компиляции, иногда в них требуется следовать более точному или более свежему синтаксису.
  • Прочтите руководство еще и еще раз, потому что невозможно все запомнить и к этому времени вы что-то забудете.
  • Читайте скрипты опции компилирования, там может прятаться полезная информация.
  • Делайте резервные копии, и держите под рукой LiveCD.

Когда вы освоите процесс, компиляция пакета из исходного кода (будь то ядро, модуль, драйвер Xorg, библиотека - да все, что угодно) станет для вас не сложнее чтения рецепта приготовления пиццы: просто не забывайте перечитывать его, и держать руки в муке - иначе тесто прилипнет.

Информация об авторских правах

This entry is (C) Copyright by its author, 2004-2008. Unless a different license is specified in the entry's body, the following license applies: "Verbatim copying and distribution of this entire article is permitted in any medium without royalty provided this notice is preserved and appropriate attribution information (author, original site, original URL) is included".