Configure and make linux

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

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

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

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

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

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

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

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

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

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

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

Перезаписана Главная Загрузочная Запись (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.

Читайте также: Debian linux with lxde

Падение ядра

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы собрались построить модуль ядра (скажем, крайне нестабильный 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), или иметь где-нибудь запасной образ ядра.

Заключение

Читайте руководства
Снова перечитайте руководства, так как некоторые места вначале станут более понятными.
Читайте файлы релиза, они иногда противоречат руководству, и вы будете знать, чего ожидать.
Проверяйте опции компиляции, иногда в них требуется следовать более точному или более свежему синтаксису.
Прочтите руководство еще и еще раз, потому что невозможно все запомнить и к этому времени вы что-то забудете.
Читайте скрипты опции компилирования, там может прятаться полезная информация.
Делайте резервные копии, и держите под рукой 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».

Источник

Configure and make linux

Система сборки Gwyddion на Unix основана на GNU autotools (autoconf, automake, libtool), так же, как и большинство современного свободного программного обеспечения и программ с открытым исходным кодом под Unix. Если вы когда-либо собирали программы из исходников, вы, вероятно, уже встречались с autotools и знаете, что делать дальше. Этот раздел, тем не менее, будет описывать процесс сборки достаточно детально, чтобы быть понятным и тем, кто ещё этого не делал. Файл INSTALL в каталоге верхнего уровня архива с исходным кодом содержит общие инструкции по установке с помощью GNU autotools.

Краткие инструкции

Если вам уже знакома последовательность действий:

tar -jxvf gwyddion-2.49.tar.xz
cd gwyddion-2.49
./configure
make
make install

Распаковка исходного кода

Распакуйте архив с исходным кодом командой

tar -Jxvf gwyddion-2.49.tar.xz

заменяя 2.49 текущим номером версии. При этом будет создан каталог gwyddion-2.49 (снова с текущим номером версии вместо 2.49), перейдите с помощью cd в этот каталог. Все остальные действия по сборке будут проходить там.

Если в операционной системе отсутствует xz, можно загрузить gwyddion-2.49.tar.gz (сжатый с помощью gzip) вместо предыдущего архива и распаковать его с помощью

tar -zxvf gwyddion-2.49.tar.gz

Однако, современные Unix и подобные им системы поддерживают и gzip, и xz, и заметно меньший gwyddion-2.49.tar.xz обычно будет более удачным вариантом.

Настройка

чтобы сконфигурировать сборку Gwyddion .

Скрипт оболочки configure пытается угадать правильные значения для различных переменных, меняющихся от системы к системе и используемых в процессе компиляции. Он использует эти переменные чтобы создать Makefile в каждом каталоге пакета, набор заголовочных файлов с расширением .h , которые содержат зависящие от системы определения и некоторые другие вспомогательные файлы. В конце своей работы он создаёт другой скрипт оболочки config.status , который можно затем использовать для повторения текущей конфигурации, и файл config.log , который содержит подробности процесса детектирования и который полезно включать в сообщения об ошибках компиляции. В конце команда configure также выводит суммарную сводку о включенных и выключенных дополнительных опциях, включая причины почему опция была выключена.

Если configure пишет об отсутствии требуемых пакетов, установите эти пакеты и перезапустите её. То же самое справедливо и для случая, если configure заканчивается успешно, но вы обнаружили, что забыли установить опциональный компонент, с которым хотели собрать Gwyddion . Возможно, что пакет не был найден или был неправильно определён даже если вы его установили, а именно если он был установлен в нестандартный каталог. В этом случае необходимо настроить определённые переменные окружения чтобы дать configure возможность найти эти пакеты:

Большинство пакетов идут вместе с так называемыми файлами pkg-config ( .pc ), которые описывают как программы должны собираться и линковаться с ними. configure использует информацию из этих файлов, следовательно, PKG_CONFIG_PATH должна быть установлена таким образом, чтобы там были перечислены все нестандартные какталоги с нужными файлами pkg-config. Чтобы добавить, например, установленную библиотеку GTK+ в /opt/gnome и установленную библиотеку FFTW3 в $HOME/opt/fftw3 , нужно выполнить:

PKG_CONFIG_PATH=/opt/gnome/lib/pkgconfig:$HOME/opt/fftw3/lib/pkgconfig
export PKG_CONFIG_PATH

Может потребоваться настроить эти переменные чтобы включить нестандартные каталоги с исполняемыми файлами и библиотеками соответствующих пакетов. Переменные LD_LIBRARY_PATH и DYLD_LIBRARY_PATH обе задают путь поиска для разделяемых библиотек, но первая используется в системах на основе Linux и BSD, в то время, как вторая на OS X.

Может потребоваться настроить эти переменные чтобы включить нестандартные каталоги с заголовочными файлами и библиотеками пакетов, с которыми не шло файлов pkg-config, например, для libTIFF в /usr/local можно установить:

CPPFLAGS=-I/usr/local/include
export CPPFLAGS
LDFLAGS=-L/usr/local/lib
export LDFLAGS

Опция —prefix команды configure задаёт базовый каталог установки. Компоненты программы будут установлены в его подкаталоги bin , lib , share , и т.д. (которые будут созданы если они не существуют). Более детальное управление возможно с помощью опций, задающих отдельные подкаталоги, таких как —bindir , —libdir . Префикс по умолчанию – /usr/local/bin , чтобы установить Gwyddion в домашний каталог пользователя можно использовать, например команду

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

Настройки процесса конфигурирования

Необязательные возможности можно включить/выключить с помощью опций вроде —with-foo / —without-foo или —enable-foo / —disable-foo . Например, компиляция с zlib может быть отключена командой:

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

Полный список опций и важных переменных configure можно получить с помощью команды:

Список будет длинным и большая часть опций контроллирует включение/выключение отдельных опциональных возможностей или передачу необходимых флагов компиляции и связывания для различных библиотек. Например, задавая FFTW3_CFLAGS и FFTW3_LIBS можно задать (или переопределить) как будет осуществляться компиляция и связывание с FFTW3. Однако, такое ручное задание является резервным вариантом для гораздо более удобного метода, основанного на использовании pkg-config в том случае если он почему-то не работает.

Некоторые интересные общие опции описаны в следующих параграфах.

Настройки пользователей

C Gwyddion поставляются различные файлы взаимодействия со средой рабочего стола, которые определяют типы MIME, элементы меню, привязки файлов, генерацию миниатюр и т.п. Если Gwyddion устанавливается в системный каталог, они обычно находятся в правильных местах файловой системы. Однако, если вы устанавливаете его куда-то в свой каталог пользователя, то эти файлы нужно поместить в другое место. а именно в определённые скрытые каталоги, начинающиеся с точки в вашем домашнем каталоге.

Это можно задать с помощью опции —enable-home-installation команды configure . Следует отметить, что использование этой опции приводит к установке файлов в каталоги вне заданного префикса.

Настройки создателей пакетов

Если Gwyddion устанавливается во временный каталог для дальнейшего создания пакета, необходимо отключить определённые действия после установки, которые нужно производить с системой, где пакет будет установлен, а не в момент создания пакета.

Обновление файлов FreeDesktop может быть отключено с помощью —disable-desktop-file-update . Установка схем GConf2 может быть отключена с помощью —disable-schemas-install . Обычно это не надо делать в явной форме т.к. установки в временный каталог используют непустую переменную DESTDIR (см. раздел установка). Если переменная DESTDIR не пустая, система сборки пропустит автоматически действия после установки. Тем не менее, обычной причиной отключения этих действий является то. что Gwyddion устанавливается на временное место вместо финального каталога (что обычно происходит при сборке пакетов в Linux). В этом случае вспомогательные действия отключаются автоматически при непустой переменной DESTDIR (см. раздел установка) и, следовательно, нет нужды отключать их в configure .

Передавая параметр —enable-library-bloat скрипту configure заставляет связываться модулям со всеми библиотеками. Это автоматически включается на MS Windows, где это является обязательным требованием. В основанных на Unix системах, связывание модулей со всеми библиотеками, которые уже загружены основной программой только напрасно замедляет работу (как во время сборки, так и во время исполнения). Таким образом, модули не связываются непосредственно с основными библиотеками вроде GLib. если ваша система или правила сборки требуют связывания модулей со всеми библиотеками (например, в системах, основанных на AltLinux), использование этой опции включает данное поведение.

Передачей опции —disable-module-bundling команде configure можно запретить объединение всех модулей одного типа (файловых, обработки данных, . ) в одну разделяемую библиотеку, что обычно делается для сохранения места на диске и ускорения загрузки. Хотя подобное объединение не меняет функциональность, оно заметно меняет набор устанавливаемых файлов. Если вы, по той или иной причине, полагаетесь на наличие на диске файла gwyfile.so , самое время остановиться и перестать так делать. Тем не менее, можно использовать данную опцию чтобы принудительно получить традиционный вариант установки, где каждый модуль находился в отдельном файле.

Настройки для разработчиков

Если вы собираетесь накладывать патч или иным образом модифицировать исходный код Gwyddion запустите configure с опцией —enable-maintainer-mode чтобы включить различные правила обновления и пересборки, которые не используются при обычной компиляции. В зависимости от вида изменений могут понадобиться некоторые дополнительные инструменты, описанные в разделе Снимок Subversion, разработка.

По умолчанию справочное руководство по C API не пересобирается. Подготовленные файлы HTML распространяются с архивом, документация меняется редко и её генерация требует достаточно продолжительного времени. Для того, чтобы включить генерацию документации по API нужно передать опцию —enable-gtk-doc скрипту configure . Естественно, вам потребуется gtk-doc. Следует отметить, что configure предупредит вас, если вы включили режим мантейнера, но выключили gtk-doc (что может быть полезно для того, чтобы не пересобирать постоянно и бесцельно документацию). Если вы не собираетесь делать make dist , это предупреждение безвредно.

Источник