Внутреннее устройство Linux

16. Введение в программное обеспечение для компиляции кода на языке C

Большинство общедоступных пакетов сторонних разработчиков ПО для Unix поставляется в виде исходного кода, который можно скомпоновать и установить. Одной из причин для этого является наличие такого числа различных версий и архитектур Unix (и самой Linux), что было бы затруднительно создать двоичные пакеты для всех возможных комбинаций платформ. Еще одна важная причина состоит в том, что широкое распространение исходного кода в Unix-сообществе воодушевляет пользователей на исправление ошибок в ПО и внесение новых функций, наполняя смыслом термин «открытый исходный код».

Практически все, что вы видите в системе Linux, можно получить как исходный код: начиная с ядра и библиотеки C и заканчивая браузерами. Возможно даже обновить и дополнить систему в целом, (пере)установив части системы из исходного кода. Однако вам, вероятно, не следует обновлять свой компьютер, устанавливая все из исходного кода, если только вы не получаете удовольствие от этого процесса или у вас нет какой-либо другой причины.

Linux обычно обеспечивает простые способы обновления важнейших частей системы, таких как команды в каталоге /bin, а одним чрезвычайно важным свойством систем является то, что они обычно очень быстро устраняют проблемы в защите. Однако не ожидайте, что ваша версия обеспечит вас всем необходимым без вашего участия. Вот несколько причин, по которым может потребоваться самостоятельно установить определенные пакеты:

• чтобы контролировать параметры конфигурации;

• чтобы установить ПО туда, куда вам необходимо. Вы можете даже установить несколько разных версий одного пакета;

• чтобы управлять версией, которую вы устанавливаете. В дистрибутивах системы не всегда присутствует самая последняя версия всех пакетов, в особенности относящихся к дополнительному ПО (такому как библиотеки Python);

• чтобы лучше понимать, как работает пакет.

16.1. Системы для сборки программного обеспечения

В Linux есть различные среды программирования, начиная от традиционного языка C и заканчивая такими интерпретируемыми языками сценариев, как Python. У каждой из них есть по меньшей мере одна собственная система для сборки и установки пакетов в дополнение к тем инструментам, которые предлагает система Linux.

В этой главе мы рассмотрим компиляцию и установку исходного кода на языке C с помощью лишь одной их таких систем — сценариев конфигурирования, создаваемых пакетом GNU Autotools. Эта система считается стабильной, и многие основные утилиты Linux используют ее. Поскольку она основана на таких существующих инструментах, как команда make, вы сможете применить свои знания для других систем сборки, увидев ее в действии.

Установка пакета из исходного кода на языке C обычно включает следующие шаги.

1. Распаковку архива с исходным кодом.

2. Конфигурирование пакета.

3. Запуск команды make для сборки команд.

4. Запуск команды make install или специфичной для данной версии ОС команды, которая устанавливает пакет.

примечание

Вы должны понимать основы, изложенные в главе 15, прежде чем продолжать чтение этой главы.

16.2. Распаковка архива с исходным кодом на языке C

Исходный код какого-либо пакета обычно предоставляется в виде файла. tar.gz, tar.bz2 или. tar.xz, и вам следует распаковать этот файл, как описано в разделе 2.18. Однако перед распаковкой проверьте содержимое архива с помощью команд tar tvf или tar ztvf, поскольку некоторые пакеты не создают собственные подкаталоги в том каталоге, где вы распаковываете архив.

Отчет, подобный приводимому ниже, свидетельствует о том, что пакет в порядке и готов для распаковки:

package-1.23/Makefile.in

package-1.23/README

package-1.23/main.c

package-1.23/bar.c

— snip—

Тем не менее вы можете обнаружить, что не все файлы находятся внутри одного каталога (вроде каталога package-1.23 из приведенного примера):

Makefile

README

main.c

— snip—

Распаковка такого архива может создать большую путаницу в вашем текущем каталоге. Чтобы избежать этого, создайте новый каталог и перейдите в него перед извлечением содержимого архива. Наконец, остерегайтесь пакетов, которые содержат файлы с абсолютными путями, вроде таких:

/etc/passwd

/etc/inetd.conf

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

С чего начать. После извлечения содержимого архива с исходным кодом и появления множества файлов перед вами попытайтесь получить представление о пакете. В частности, поищите файлы README и INSTALL. Обязательно загляните в каждый файл README, поскольку они часто содержат описание пакета, краткое руководство, советы по установке и другую полезную информацию. Многие пакеты сопровождаются также файлами INSTALL, содержащими инструкции по компиляции и установке пакета. Особое внимание уделите специальным параметрам компилятора и определениям.

В дополнение к файлам README и INSTALL вы найдете другие файлы пакета, которые можно грубо распределить по трем категориям.

• Файлы, относящиеся к команде make, такие как Makefile, Makefile.in, configure и CMakeLists.txt. Очень старые пакеты содержат файл Makefile, который вам может понадобиться изменить, но большинство пакетов использует утилиту конфигурирования, например GNU Autoconf или CMake. Они поставляются с файлом сценария или конфигурации (такими как configure или CMakeLists.txt), чтобы помочь создать файл Makefile из файла Makefile.in, основываясь на настройках вашей системы и параметрах конфигурации.

• Файлы исходного кода, имена которых оканчиваются на. c, h или. cc. Файлы исходного кода на языке C могут появиться практически всюду в каталоге пакета. У файлов исходного кода на языке C++ обычно есть суффиксы. cc, C или. cxx.

• Объектные файлы, имена которых оканчиваются на. o, или двоичные файлы. Обычно объектные файлы отсутствуют в пакетах с исходным кодом, но вы можете встретить их в редких случаях, когда поставщику пакета не разрешено распространение исходного кода и вам необходимо предпринимать что-либо особое, чтобы использовать такие объектные файлы. В большинстве случаев наличие объектных (или двоичных исполняемых) файлов в пакете означает, что он был составлен не очень хорошо и вам следует запустить команду make clean, чтобы убедиться в пригодности кода для компиляции.

16.3. Утилита GNU Autoconf

Хотя исходный код на языке C обычно довольно хорошо портируется, различия между платформами делают невозможной компиляцию большинства пакетов с помощью единственной утилиты Makefile. Раньше для решения этой проблемы предлагались отдельные утилиты Makefile для каждой операционной системы или же утилита, которую легко изменять. При таком подходе приходилось задействовать сценарии, которые генерируют файлы Makefiles на основе анализа системы, использованной для сборки пакета.

Утилита GNU Autoconf является популярным средством для автоматического создания файла Makefile. Пакеты, которые используют эту систему, содержат файлы с именами configure, Makefile.in и config.h.in. Файлы с суффиксом. in являются шаблонами; идея состоит в том, чтобы запускать сценарий конфигурирования, который выявляет характеристики вашей системы, а затем выполняет подстановки в файлах. in для создания реальных файлов сборки. Для конечного пользователя это просто; чтобы создать файл Makefile из файла Makefile.in, запустите команду configure:

$ ./configure

Вы должны получить пространный диагностический вывод, пока сценарий проверяет вашу систему на соответствие необходимым условиям. Если все завершается удачно, команда configure создает один или несколько файлов Makefile и файл config.h, а также файл кэша (config.cache), чтобы ей не приходилось выполнять некоторые проверки заново.

Теперь можно запустить команду make для компиляции пакета. Успешное прохождение этапа с командой configure не обязательно означает, что этап make тоже будет пройден, но шансы на это весьма велики (см. раздел 16.6, чтобы разобраться с неудачными результатами конфигурирования и компиляции).

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

примечание

Для этого вам требуется иметь все необходимые инструменты сборки, которые доступны в вашей системе. Для Debian и Ubuntu простейшим способом является установка пакета, существенного для сборки; для систем, подобных Fedora, воспользуйтесь утилитой groupinstall.

16.3.1. Пример работы утилиты Autoconf

Прежде чем обсуждать то, как вы можете изменить поведение утилиты Autoconf, посмотрим на простой пример, чтобы вы знали, чего ожидать. Вы будете устанавливать пакет GNU coreutils в ваш домашний каталог (для гарантии того, что он не смешается с вашей системой). Скачайте пакет с веб-страницы http://ftp.gnu.org/gnu/coreutils/ (обычно самой лучшей является последняя версия), распакуйте его, перейдите в распакованный каталог и выполните конфигурирование таким образом:

$ ./configure — prefix=$HOME/mycoreutils

checking for a BSD-compatible install… /usr/bin/install — c

checking whether build environment is sane… yes

— snip—

config.status: executing po-directories commands

config.status: creating po/POTFILES

config.status: creating po/Makefile

Теперь запустите команду make:

$ make

GEN lib/alloca.h

GEN lib/c++defs.h

— snip—

make[2]: Leaving directory '/home/juser/coreutils-8.22/gnulib-tests'

make[1]: Leaving directory '/home/juser/coreutils-8.22'

Далее попробуйте запустить один из исполняемых файлов, только что созданных вами, например./src/ls, и попытайтесь выполнить команду make check, чтобы осуществить ряд проверок пакета. На это может потребоваться некоторое время, но наблюдать за проверкой интересно.

Наконец вы готовы к установке пакета. Выполните сначала пробный прогон с помощью команды make — n, чтобы увидеть то, что выполняет команда make install, но не устанавливая сам пакет:

$ make — n install

Просмотрите результат работы и, если не заметите никаких странностей (таких как установка в каталог, отличающийся от каталога mycoreutils), выполните реальную установку:

$ make install

Теперь в вашем домашнем каталоге должен появиться подкаталог с именем mycoreutils, содержащий подкаталоги bin, share и др. Попробуйте запустить некоторые команды из каталога bin (вы только что выполнили сборку многих основных инструментов, о которых узнали из главы 2). Наконец, поскольку вы настроили каталог mycoreutils так, чтобы он не зависел от остальной части системы, можно полностью удалить его, не опасаясь причинить вред системе.

16.3.2. Установка с помощью инструментов для создания пакетов

В большинстве версий ОС возможно устанавливать новое ПО как пакет, который в дальнейшем вы можете обслуживать с помощью инструментов для работы с пакетами. Версии системы на основе Debian, например Ubuntu, вероятно, наиболее просты: вместо запуска обычной команды make install можно выполнить установку с помощью утилиты checkinstall следующим образом:

# checkinstall make install

Используйте параметр — pkgname=name, чтобы указать имя для нового пакета.

Создание пакета RPM выполняется немного сложнее, поскольку сначала вы должны создать дерево каталогов для ваших пакетов. Это можно сделать с помощью команды rpmdev-setuptree; по ее выполнении можно применить утилиту rpmbuild, чтобы осуществить оставшиеся шаги. В этом процессе лучше всего следовать интерактивному руководству.

16.3.3. Параметры сценария configure

Вы только что увидели один из самых полезных параметров сценария configure: использование — prefix для указания каталога установки. По умолчанию цель команды install из созданного утилитой Autoconf файла Makefile использует префикс /usr/local — то есть двоичные команды отправляются в каталог /usr/local/bin, библиотеки в каталог /usr/local/lib и т. д. Вам часто потребуется изменить этот префикс подобным образом:

$ ./configure — prefix=new_prefix

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

• —bindir=directory. Устанавливает исполняемые файлы в каталог directory.

• —sbindir=directory. Устанавливает системные исполняемые файлы в каталог directory.

• —libdir=directory. Устанавливает библиотеки в каталог directory.

• —disable-shared. Предотвращает создание совместно используемых библиотек для пакета. В зависимости от библиотеки в дальнейшем это может помочь избежать неприятностей (см. подраздел 15.1.4).

• —with-package=directory. Говорит сценарию configure о том, что пакет package находится в каталоге directory. Это удобно, когда необходимая библиотека расположена в нестандартном месте. К сожалению, не все сценарии конфигурирования распознают этот тип параметра, а выяснить точный синтаксис для них бывает затруднительно.

Использование отдельных каталогов сборки

Можно создать отдельные каталоги для сборки, если вы желаете поэкспериментировать с некоторыми из параметров. Чтобы это сделать, создайте новый каталог где-либо в системе и из этого каталога запустите сценарий configure в каталоге исходного кода пакета. Вы обнаружите, что при этом сценарий configure создаст ферму символических ссылок в вашем новом каталоге, где все ссылки указывают на дерево источника в исходном каталоге пакета. Некоторые разработчики предпочитают, чтобы вы собирали пакеты именно так, поскольку при этом не изменяется дерево источника. Это полезно также, если вы желаете собрать с помощью одного исходного пакета несколько версий для разных платформ или параметров конфигурации.

16.3.4. Переменные окружения

Можно повлиять на сценарий configure с помощью переменных окружения, которые сценарий configure помещает в переменные утилиты make. Самыми важными являются переменные CPPFLAGS, CFLAGS и LDFLAGS. Но будьте осторожны: сценарий configure может оказаться весьма требовательным к переменным окружения. Например, обычно вам следует использовать переменную CPPFLAGS вместо переменной CFLAGS для каталогов с заголовочными файлами, поскольку сценарий configure часто запускает препроцессор независимо от компилятора.

В оболочке bash простейший способ отправить переменную окружения сценарию configure — это поместить назначение переменной перед фрагментом./configure в командной строке. Например, чтобы создать макроопределение DEBUG для препроцессора, используйте следующую команду:

$ CPPFLAGS=-DDEBUG./configure

примечание

Можно также передать переменную как параметр для сценария configure, например так:

$./configure CPPFLAGS=-DDEBUG

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

$ CPPFLAGS=-Iinclude_dir./configure

Как показано в подразделе 15.2.6, чтобы компоновщик заглянул в каталог lib_dir, используйте следующую команду:

$ LDFLAGS=-Llib_dir./configure

Если в каталоге lib_dir есть совместно используемые библиотеки (см. подраздел 15.1.4), то приведенная команда, вероятно, не будет определять путь для динамической компоновки времени исполнения. В таком случае используйте параметр компоновщика — rpath в дополнение к флагу — L:

$ LDFLAGS="-Llib_dir — Wl, — rpath=lib_dir"./configure

Будьте внимательны при назначении переменных. Небольшая ошибка может сбить с толку компилятор и завершить компиляцию неудачей. Допустим, вы забыли дефис во флаге — I, как показано здесь:

$ CPPFLAGS=Iinclude_dir./configure

Это приведет к следующей ошибке:

configure: error: C compiler cannot create executables

See 'config.log' for more details

Если покопаться в журнале config.log, созданном при этой неудачной попытке, то можно обнаружить следующее:

configure:5037: checking whether the C compiler works

configure:5059: gcc Iinclude_dir conftest.c >&5

gcc: error: Iinclude_dir: No such file or directory

configure:5063: $? = 1

configure:5101: result: no

16.3.5. Цели утилиты Autoconf

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

• make clean. Удаляются все объектные файлы, исполняемые файлы и библиотеки.

• make distclean. Эта цель подобна цели make clean, но при этом удаляются все автоматически созданные файлы, включая Makefiles, config.h, config.log и т. п. Идея в том, чтобы дерево источника выглядело как только что распакованный дистрибутив после выполнения команды make distclean.

• make check. Некоторые пакеты поставляются с обоймой тестов для проверки правильности работы скомпилированных программ; команда make check запускает эти тесты.

• make install-strip. Подобна make install, но при установке из исполняемых файлов и библиотек удаляется таблица имен и другая отладочная информация. Для урезанных двоичных файлов требуется намного меньше места.

16.3.6. Файлы журналов утилиты Autoconf

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

Общий подход к поиску проблем заключается в переходе к самому концу файла config.log (нажатием, например, клавиши G в команде less) и дальнейшей прокрутке назад, пока не обнаружится проблема. Однако при этом для проверки по-прежнему остается довольно много информации, поскольку сценарий configure помещает сюда все окружение, включая переменные вывода, переменные кэша и другие определения. По этой причине вместо того, чтобы переходить в конец и прокручивать результат вверх, перейдите в конец вывода и выполните поиск в обратном направлении, указав строку for more details или какую-либо другую часть недалеко от конца ошибочного вывода сценария configure. Напомню, что поиск в обратном направлении можно запустить в команде less с помощью команды?. Весьма велики шансы на то, что ошибка окажется как раз над той строкой, которая была найдена при поиске.

16.3.7. Команда pkg-config

Существует настолько много библиотек сторонних разработчиков, что размещение их всех в общем расположении может привести к путанице. Однако и установка каждой из них с помощью отдельного префикса может вызвать проблемы, когда при сборке пакетов эти библиотеки понадобятся. Если, например, вы желаете скомпилировать пакет OpenSSH, вам необходима библиотека OpenSSL. Как сообщить процессу конфигурирования пакета OpenSSH о том, где расположены библиотеки OpenSSL и какие из них потребуются?

Многие пакеты используют теперь команду pkg-config не только для информирования о местоположении своих включаемых файлов и библиотек, но также и для указания точных флагов, которые вам необходимы для компиляции и сборки программ. Синтаксис выглядит так:

$ pkg-config options package1 package2…

Чтобы, например, отыскать библиотеки, необходимые для пакета OpenSSL, можно запустить следующую команду:

$ pkg-config — libs openssl

Результат будет вроде этого:

— lssl — lcrypto

Чтобы увидеть список всех библиотек, о которых знает команда pkg-config, запустите такую команду:

$ pkg-config — list-all

Как работает команда pkg-config

Если заглянуть за кулисы, то можно обнаружить, что команда pkg-config отыскивает информацию о пакете, читая файл конфигурации, имя которого оканчивается на. pc. Вот пример того, так выглядит файл openssl.pc для библиотеки сокетов OpenSSL в системе Ubuntu (он расположен в каталоге /usr/lib/i386-linux-gnu/pkgconfig):

prefix=/usr

exec_prefix=${prefix}

libdir=${exec_prefix}/lib/i386-linux-gnu

includedir=${prefix}/include

Name: OpenSSL

Description: Secure Sockets Layer and cryptography libraries and tools

Version: 1.0.1

Requires:

Libs: — L${libdir} — lssl — lcrypto

Libs.private: — ldl — lz

Cflags: — I${includedir} exec_prefix=${prefix}

Можно изменить этот файл, добавив, например, флагам библиотеки параметр — Wl, — rpath=${libdir}, чтобы указать путь динамической компоновки времени исполнения. Однако на первом месте остается более серьезный вопрос: как команда pkg-config отыскивает файлы. pc? По умолчанию команда pkg-config смотрит каталог lib/pkgconfig в соответствии с префиксом установки. Например, команда pkg-config, установленная с префиксом /usr/local, будет смотреть каталог /usr/local/lib/pkgconfig.

Установка файлов команды pkg-config в нестандартных размещениях

К сожалению, по умолчанию команда pkg-config не читает никаких файлов. pc за пределами своего каталога установки. Если файл. pc находится в нестандартном месте, например в каталоге /opt/openssl/lib/pkgconfig/openssl.pc, то он будет недоступен для любой стандартно установленной команды pkg-config. Есть два основных способа сделать файлы. pc доступными за пределами каталога установки команды pkg-config.

• Создать символические ссылки (или копии) из реальных файлов. pc в основном каталоге pkgconfig.

• Определить переменную окружения PKG_CONFIG_PATH так, чтобы она содержала все дополнительные каталоги. Эта стратегия работает неудовлетворительно с точки зрения системы в целом.

16.4. Практика установки

Хорошо знать о том, как собирать и устанавливать программы, но еще полезнее знать о том, когда и где устанавливать собственные пакеты программ. В дистрибутивы Linux стараются уместить максимально возможное количество программ, и вам всегда следует проверять, будет ли лучше, если вы установите пакет ПО самостоятельно. Вот преимущества самостоятельной установки программ:

• можно настроить параметры по умолчанию;

• при установке пакета возникает более ясное представление о том, как его применять;

• вы управляете тем релизом, который запускаете;

• проще создать резервную копию пользовательского пакета;

• проще распространить по сети самоустанавливающиеся пакеты (до тех пор пока архитектура совместима и местоположение для установки изолировано).

Но есть и неудобства:

• на это требуется время;

• пользовательские пакеты не обновляются автоматически. Дистрибутивы обновляют большинство пакетов, не требуя больших трудов. В особенности это относится к пакетам, которые взаимодействуют с сетью, поскольку вам необходимо быть уверенными в том, что применены последние обновления защиты;

• если вы реально не используете пакет, то вы напрасно тратите время;

• есть вероятность неправильной конфигурации пакетов.

Нет особого смысла в установке таких пакетов, как, например, coreutils, который мы собирали в этой главе чуть выше (ls, cat и т. д.), если только вы не собираетесь создать особенную систему. С другой стороны, если вы проявляете живой интерес к сетевым серверам, таким как Apache, то лучший способ получить полный контроль над ним — установить его самостоятельно.

Куда устанавливать. Префикс по умолчанию в утилите GNU Autoconf и многих других пакетах — /usr/local, традиционный каталог для устанавливаемого локального ПО. Обновления операционной системы игнорируют каталог /usr/local, поэтому вы не потеряете ничего из установленного в нем во время обновления ОС. Для небольших локальных программ каталог /usr/local подходит. Единственная проблема заключается в том, что большое количество установленных программ превращается в месиво. Тысячи странных маленьких файлов могут оказаться внутри каталога /usr/local, и у вас не будет ни малейшего понятия о том, откуда они.

Если все настолько вышло из-под контроля, следует создавать собственные пакеты, как рассказано в подразделе 16.3.2.

16.5. Применение исправлений

Большинство изменений в исходном коде программного обеспечения доступно в виде ветвей от исходного кода разработчика (например, репозиторий git). Тем не менее то и дело вам может потребоваться применить исправление к исходному коду, чтобы избавиться от ошибок или добавить новые функции. Вы можете также встретить термин diff, используемый как синоним, поскольку исправление выполняется с помощью команды diff.

Начало исправления может выглядеть таким образом:

— src/file.c.orig 2015-07-17 14:29:12.000000000 +0100

+++ src/file.c 2015-09-18 10:22:17.000000000 +0100

@@ -2,16 +2,12 @@

Исправления обычно содержат изменения для нескольких файлов. Отыщите строку с тремя дефисами подряд (—), чтобы понять, какие файлы изменены, и всегда смотрите начало исправления, чтобы определить рекомендуемый рабочий каталог. Обратите внимание на то, что приведенный пример ссылается на файл src/file.c. Следовательно, до применения исправления вы должны перейти в каталог, который содержит каталог src, но не в сам каталог src.

Чтобы применить исправление, запустите команду patch:

$ patch — p0 < patch_file

Если все пройдет успешно, команда patch незаметно завершит свою работу, оставив вам обновленный набор файлов. Однако она может задать вам такой вопрос:

File to patch:

Обычно это означает, что вы находитесь не в том каталоге, но может свидетельствовать также о том, что ваш исходный код не соответствует исходному коду в исправлении. В таком случае вам, вероятно, не повезло: даже если вам удалось бы определить некоторые файлы, подлежащие исправлению, другие остались бы не обновленными, и тогда исходный код не удастся скомпилировать.

В некоторых случаях можно встретить исправление, которое ссылается на версию пакета, например, так:

— package-3.42/src/file.c.orig 2015-07-17 14:29:12.000000000 +0100

+++ package-3.42/src/file.c 2015-09-18 10:22:17.000000000 +0100

Если номер вашей версии немного отличается (или вы просто переименовали каталог), можно дать указание команде patch, чтобы она обрезала начальные элементы пути. Допустим, например, что вы находитесь в каталоге, который содержит каталог src (как выше). Чтобы команда patch игнорировала часть пути package-3.42/ (то есть отрезала один начальный фрагмент пути), используйте флаг — p1:

$ patch — p1 < patch_file

16.6. Устранение проблем при компиляции и установке

Если вы усвоили различия между ошибками и предупреждениями компилятора, ошибками компоновщика и проблемами, связанными с совместно используемыми библиотеками, как рассказано в главе 15, у вас не должно возникнуть много сложностей при исправлении большинства глюков, которые возникают при сборке программ. Этот раздел описывает некоторые распространенные проблемы. Хотя маловероятно, что при использовании утилиты Autoconf вам встретится что-либо подобное, никогда не повредит узнать о том, как выглядят такие проблемы.

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

make: *** [target] Error 1

Однако некоторые файлы Makefiles подозревают, что может возникнуть условие для какой-либо ошибки, но они знают, что такие ошибки безвредны. Обычно можно не обращать внимания на такие сообщения:

make: *** [target] Error 1 (ignored)

Команда GNU make часто вызывает себя многократно для больших пакетов, и каждый ее экземпляр отмечен в сообщениях об ошибках с помощью символов [N], где N является числом. Зачастую можно быстро отыскать ошибку, посмотрев на то сообщение об ошибке команды make, которое идет сразу после ошибки компилятора. Например:

[compiler error message involving file.c]

make[3]: *** [file.o] Error 1

make[3]: Leaving directory '/home/src/package-5.0/src'

make[2]: *** [all] Error 2

make[2]: Leaving directory '/home/src/package-5.0/src'

make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/src/package-5.0/'

make: *** [all] Error 2

Первые три строки практически выдают ее: проблема связана с файлом file.c, который расположен в каталоге /home/src/package-5.0/src. К сожалению, дополнительной информации так много, что бывает сложно найти важные детали. Выяснение того, как отфильтровать более поздние ошибки утилиты make, позволит отыскать настоящую причину.

Особые ошибки. Вот несколько распространенных ошибок сборки, которые могут вам встретиться.

Ошибка

Сообщение об ошибке компилятора:

src.c:22: conflicting types for 'item'

/usr/include/file.h:47: previous declaration of 'item'

Объяснение и устранение

Программист выполнил ошибочное повторное объявление элемента item в строке 22 файла src.c. Обычно это можно исправить, удалив ошибочную строку (с помощью комментария, директивы #ifdef или чего-либо подобного).

Ошибка

Сообщение об ошибке компилятора:

src.c:37: 'time_t' undeclared (first use this function)

— snip—

src.c:37: parse error before '…'

Объяснение и устранение

Программист забыл важный заголовочный файл. Страницы руководства лучше всего помогут в отыскании упущенного файла. Сначала посмотрите на ошибочную строку (в данном случае это строка 37 в файле src.c). Вероятно, она содержит объявление переменной вроде следующего:

time_t v1;

Отыщите в программе строку, в которой переменная v1 использует вызов какой-либо функции. Например, так:

v1 = time(NULL);

Теперь запустите команды man 2 time или man 3 time, чтобы отыскать системные и библиотечные вызовы с именем time(). В данном случае подходит второй раздел страницы руководства:

SYNOPSIS

#include

time_t time(time_t *t);

Это означает, что вызову time() необходим файл time.h. Поместите строку #include в начало файла src.c и попробуйте еще раз.

Ошибка

Сообщение об ошибке компилятора (препроцессора):

src.c:4: pkg.h: No such file or directory

(long list of errors follows)

Объяснение и устранение

Компилятор запустил препроцессор C для файла src.c, но не смог найти включаемый файл pkg.h. Исходный код, вероятно, зависит от библиотеки, которую необходимо установить, или же необходимо указать для компилятора нестандартный путь с включаемыми файлами. Как правило, вам понадобится лишь добавить параметр — I к флагам препроцессора C (CPPFLAGS), чтобы добавить этот путь. Помните о том, что может также понадобиться флаг компоновщика — L, чтобы использовать эти включаемые файлы.

Если ситуация не похожа на отсутствие библиотеки, есть незначительная вероятность того, что вы пытаетесь скомпилировать файл для операционной системы, которая не поддерживается данным исходным кодом. Ознакомьтесь с файлами Makefile и README, чтобы узнать подробности о платформах.

Если вы работаете с версией ОС на основе Debian, попробуйте применить команду apt-file к имени заголовочного файла:

$ apt-file search pkg.h

Это может выявить необходимый пакет разработки. Для версий, которые содержат утилиту yum, попробуйте такой вариант:

$ yum provides */pkg.h

Ошибка

Сообщение утилиты make:

make: prog: Command not found

Объяснениеи устранение

Чтобы собрать пакет, в вашей системе должна быть программа prog. Если таковой является что-либо вроде cc, gcc или ld, то в системе не установлены утилиты для разработки. С другой стороны, если вы полагаете, что команда prog уже установлена в системе, попробуйте изменить файл Makefile, чтобы выяснить полный путь к команде prog.

В редких случаях команда make собирает программу prog, а затем немедленно ее использует, считая, что текущий каталог (.) расположен в командном пути. Если переменная $PATH не содержит текущий каталог, можно отредактировать файл Makefile и изменить prog на ./prog. Как вариант, можно было бы на время добавить точку к имени пути.

16.7. Заглядывая вперед

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

• Понимание того, как использовать другие системы компоновки, кроме утилиты Autoconf (например, CMake и SCons).

Настройка сборок для вашего ПО. Если вы разрабатываете собственные программы, вам необходимо выбрать систему сборки и научиться применять ее. При создании пакетов с помощью утилиты GNU Autoconf вам может пригодиться книга Джона Кэлкоута (John Calcote) Autotools («Утилиты Autotools») (No Starch Press, 2010).

Компиляция ядра системы Linux. Система сборки ядра полностью отличается от других инструментов. У нее есть собственная система конфигурирования, предназначенная для точной подгонки под ваше ядро и модули. Однако сама процедура проста. Если вы понимаете, как работает загрузчик системы, у вас не возникнет никаких затруднений. Тем не менее следует с осторожностью заниматься этим: всегда проверяйте, что у вас под рукой есть старое ядро на тот случай, когда вы не сможете загрузиться с помощью нового.

Специализированные пакеты исходного кода. Дистрибутивы Linux поддерживают собственные версии исходного программного кода в качестве специальных пакетов исходного кода. Иногда могут оказаться полезными исправления, которые расширяют функциональность или исправляют ошибки, недоступные для исправления как-либо иначе. Системы для управления пакетами исходного кода содержат инструменты для автоматической сборки, например debuild в Debian и mock для систем на основе RPM.

Сборка программного обеспечения — это зачастую стартовая площадка для изучения языков программирования и методов разработки ПО. Инструменты, которые вы видели в последних двух главах, снимают завесу тайны с того, откуда берутся ваши системные программы. Совсем несложно выполнить дальнейшие шаги: заглянуть в исходный код, внести изменения и создать собственную программу.