-->

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

На нашем литературном портале можно бесплатно читать книгу Внутреннее устройство Linux, Уорд Брайан-- . Жанр: Программное обеспечение / Программирование / ОС и Сети. Онлайн библиотека дает возможность прочитать весь текст и даже без регистрации и СМС подтверждения на нашем литературном портале bazaknig.info.
Внутреннее устройство Linux
Название: Внутреннее устройство Linux
Дата добавления: 16 январь 2020
Количество просмотров: 496
Читать онлайн

Внутреннее устройство Linux читать книгу онлайн

Внутреннее устройство Linux - читать бесплатно онлайн , автор Уорд Брайан

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

Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала

Перейти на страницу:

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 с помощью команды ?. Весьма велики шансы на то, что ошибка окажется как раз над той строкой, которая была найдена при поиске.

Перейти на страницу:
Комментариев (0)
название