Содержание

• 8.1. Введение
• 8.2. Управление пакетами
• 8.5. Glibc-2.39
• 8.6. Zlib-1.3.1
• 8.12. M4-1.4.19
• 8.18. Pkgconf-2.1.1
• 8.19. Binutils-2.42
• 8.20. GMP-6.3.0
• 8.23. Attr-2.5.2
• 8.24. Acl-2.3.2
• 8.28. GCC-13.2.0
• 8.33. Bison-3.8.2
• 8.35. Bash-5.2.21
• 8.42. Perl-5.38.2
• 8.45. Autoconf-2.72
• 8.46. Automake-1.16.5
• 8.47. OpenSSL-3.2.1
• 8.51. Python-3.12.2
• 8.63. GRUB-2.12
• 8.64. Gzip-1.13
• 8.68. Make-4.4.1
• 8.69. Patch-2.7.6
• 8.71. Texinfo-7.1
• 8.72. Vim-9.1.0041
• 8.75. Systemd-255
• 8.77. Man-DB-2.12.0
• 8.79. Util-linux-2.39.3
• 8.81. Об отладочных символах
• 8.82. Удаление отладочных символов
• 8.83. Очистка

В этой главе мы приступаем к сборке конечной системы LFS.

Установка программного обеспечения проста. Хотя во многих случаях инструкции по установке можно было бы сделать короче и универсальнее, мы решили предоставить полные инструкции для каждого пакета, чтобы свести к минимуму вероятность ошибок. Ключом к пониманию того, что заставляет систему Linux работать, является знание того, для чего используется каждый пакет и зачем он вам (или системе) может понадобиться.

Мы не рекомендуем использовать оптимизации. С ними программа может работать немного быстрее, но также они могут вызвать сложности при компиляции и проблемы при запуске программы. Если пакет не компилируется при использовании оптимизации, попробуйте скомпилировать его без оптимизации и посмотрите, решает ли это проблему. Даже если пакет компилируется при использовании оптимизации, существует риск, что он может быть скомпилирован неправильно из-за сложных взаимодействий между кодом и инструментами сборки. Также обратите внимание, что параметры -march и -mtune, не тестировались со значениями отличными от указанных в книге. Это может вызвать проблемы с пакетами набора инструментов (Binutils, GCC и Glibc). Небольшие потенциальные плюсы, достигаемые за счет оптимизации, часто перевешиваются рисками. Тем кто собирает LFS впервые рекомендуется делать это без пользовательских оптимизаций.

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

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

Как правило, редакторы LFS не рекомендуют собирать и устанавливать статические библиотеки. Большинство статических библиотек устарели в современной системе Linux. Кроме того, линковка статической библиотеки с программой может быть вредна. Если для устранения проблемы безопасности требуется обновление библиотеки, все программы, использующие статическую библиотеку, необходимо будет повторно перелинковать с новой библиотекой. Поскольку использование статических библиотек не всегда очевидно, соответствующие программы (и процедуры, необходимые для линковки) могут быть даже неизвестны.

В инструкциях этой главы мы удаляем или отключаем установку большинства статических библиотек. Обычно это делается путем передачи параметра –disable-static при выполнении configure. Иногда необходимо использовать альтернативные методы. В некоторых случаях, в частности в пакетах Glibc и GCC, использование статических библиотек остается важным элементом процесса сборки пакетов.

Более подробное обсуждение библиотек смотрите Библиотеки: статические или общие? в книге BLFS.

Управление пакетами — часто cпрашиваемое дополнение к книге LFS. Менеджер пакетов позволяет отслеживать установку файлов, упрощая удаление и обновление пакетов. Хороший менеджер пакетов также будет обрабатывать конфигурационные файлы, чтобы сохранить пользовательские настройки при переустановке или обновлении пакета. Прежде чем вы начнете задаваться вопросом, НЕТ—в этом разделе не будет ни говориться, ни рекомендоваться какой-либо конкретный менеджер пакетов. Что он действительно предоставляет, так это обзор наиболее популярных методов и того, как они работают. Идеальным менеджером пакетов для вас может быть один из этих методов или комбинация двух и более методов. В этом разделе кратко упоминаются проблемы, которые могут возникнуть при обновлении пакетов.

Некоторые причины, по которым менеджер пакетов не упоминается в LFS или BLFS представлены ниже:

• Рассмотрение управления пакетами отвлекает внимание от целей этих книг—обучения тому, как строится система Linux.
• Существует множество решений для управления пакетами, каждое из которых имеет свои сильные и слабые стороны. Трудно найти такое, которое удовлетворит всех.

Есть несколько советов, написанных на тему управления пакетами. Посетите проект Советы возможно вы найдете решение, которое соответствует вашим потребностям.

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

• Если нужно обновить ядро Linux (например, с 5.10.17 до 5.10.18 или 5.11.1), дополнительно пересобирать ничего не нужно. Система продолжит нормально работать благодаря четко определенной границе между ядром и пользовательским пространством. В частности, заголовки Linux API не нужно обновлять вместе с ядром. Вам просто нужно перезагрузить систему, чтобы использовать обновленное ядро.

• Если необходимо обновить Glibc до более новой версии (например, с Glibc-2.36 до Glibc-2.39) необходимо выполнить некоторые дополнительные действия, чтобы избежать поломки системы. Подробности читайте в Разделе 8.5. «Glibc-2.39».

• Если пакет, содержащий общую библиотеку, обновляется и имя библиотеки изменилось, то любые пакеты, динамически связанные с библиотекой, необходимо перекомпилировать, чтобы связать с более новой библиотекой. (Обратите внимание, что между версией пакета и именем библиотеки нет никакой связи.) Например, рассмотрим пакет foo-1.2.3, который устанавливает общую библиотеку с именем libfoo.so.1. Предположим, вы обновили пакет до более новой версии foo-1.2.4, которая устанавливает общую библиотеку с именем libfoo.so.2, все пакеты, которые динамически связаны с libfoo.so.1, должны быть перекомпилированы для связи с libfoo.so.2, чтобы использовать новую версию библиотеки. Вы не должны удалять старые библиотеки, пока все зависимые пакеты не будут перекомпилированы.

• Если пакет (прямо или косвенно) связан как со старым, так и с новым именем общей библиотеки (например, пакет ссылается как на libfoo.so.2, так и на libbar.so.1, в то время как последний ссылается на libfoo.so.3), пакет может работать неправильно, поскольку разные версии общей библиотеки содержат несовместимые определения для некоторых имен символов. Это может быть вызвано перекомпиляцией некоторых, но не всех, пакетов, связанных со старой общей библиотекой, после обновления пакета, предоставляющего общую библиотеку. Чтобы избежать этой проблемы, пользователям необходимо как можно скорее пересобрать каждый пакет, связанный с общей библиотекой, с обновленной версией (например, с libfoo.so.2 на libfoo.so.3).

• Если пакет, содержащий общую библиотеку, обновляется, а имя библиотеки не меняется, но уменьшается номер версии файла библиотеки (например, библиотека по-прежнему называется libfoo.so.1, но имя файла библиотеки изменилось с libfoo.so.1.25 на libfoo.so.1.24), следует удалить файл библиотеки ранее установленной версии (в данном случае libfoo.so.1.25). В противном случае, команда ldconfig (запущенная самостоятельно с помощью командной строки или при установке какого-либо пакета) приведёт к сбросу символической ссылки libfoo.so.1, которая будет указывать на старый файл библиотеки, потому что кажется, что она имеет «более новую» версию, поскольку её номер версии больше. Такая ситуация может произойти, если вам нужно понизить версию пакета или авторы изменили схему управления версиями файлов библиотеки.

• Если пакет, содержащий общую библиотеку, обновляется, а имя библиотеки не меняется, но устраняется серьезная проблема (особенно уязвимость в системе безопасности), необходимо перезапустить все работающие программы, связанные с общей библиотекой. Следующая команда, запущенная от имени пользователя root после завершения обновления, выведет список программ, которые использует старые версии этих библиотек (замените libfoo именем библиотеки):

grep -l 'libfoo.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u

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

Если демон systemd (работающий как PID 1) связан с обновленной библиотекой, вы можете перезапустить его без перезагрузки, запустив systemctl daemon-reexec от имени пользователя root.

• Если исполняемая программа или библиотека перезаписаны, процессы, использующие код или данные из них, могут завершиться сбоем. Правильный способ обновить программу или общую библиотеку, не вызывая сбоя процесса, - это сначала удалить его, а затем установить новую версию. Команда install, предоставляемая Coreutils, уже реализовала это, и большинство пакетов используют ее для установки двоичных файлов и библиотек. Это означает, что большую часть времени вас не будет беспокоить эта проблема. Однако процесс установки некоторых пакетов (в частности, SpiderMonkey в BLFS) просто перезаписывает файл, если он существует, и вызывает сбой. Поэтому безопаснее сохранить свою работу и закрыть ненужные запущенные программы перед обновлением пакета.

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

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

Это упрощенный метод управления пакетами, для которого не требуется специальная программа управления. Каждый пакет устанавливается в отдельный каталог. Например, пакет foo-1.1 устанавливается в /opt/foo-1.1, а символическая ссылка создается из /opt/foo в /opt/foo-1.1. Когда появляется новая версия foo-1.2, она устанавливается в /opt/foo-1.2 и предыдущая символическая ссылка заменяется символической ссылкой на новую версию.

Переменные окружения, такие как PATH, MANPATH, INFOPATH, PKG_CONFIG_PATH, CPPFLAGS, LDFLAGS и файл конфигурации /etc/ld.so.conf, возможно, потребуется расширить, включив соответствующие подкаталоги в /opt/foo-x.y.

Этот подход используется в книге BLFS для установки некоторых очень больших пакетов, чтобы упростить их обновление. Если вы устанавливаете много таких пакетов, эта схема становится неуправляемой. Некоторые пакеты (например, заголовки Linux API и Glibc) могут плохо работать с такой структурой. Никогда не используйте её в масштабах всей системы.

Это разновидность предыдущей техники.Каждый пакет устанавливается аналогично, но вместо создания символической ссылки на общее имя пакета, каждому файлу создаётся символическая ссылка в иерархии каталогов /usr. Это исключает необходимость модификации значений переменных окружения. Хотя такие ссылки могут быть созданы пользователем, многие менеджеры пакетов используют именной такой подход. Наиболее популярные из них - Stow, Epkg, Graft и Depot.

Установку нужно сымитировать, чтобы пакет думал, что он установлен в /usr, хотя на самом деле он установлен в иерархии /usr/pkg. Установка таким способом обычно является нетривиальной задачей. Например, предположим, что вы устанавливаете пакет libfoo-1.1. Следующие инструкции могут привести к неправильной установке пакета:

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

Установка будет выполнена, но зависимые пакеты не смогут ссылаться на libfoo. Если вы скомпилируете пакет, который ссылается на libfoo, вы заметите, что он связан с /usr/pkg/libfoo/1.1/lib/libfoo.so.1 вместо /usr/lib/libfoo.so.1, как вы ожидаете. Правильный подход заключается в использовании переменной DESTDIR для управления установкой. Этот подход работает следующим образом:

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install

В этом методе файлу присваивается временная метка перед установкой пакета. После установки простое использование команды find с соответствующими параметрами может создать журнал всех файлов, установленных после создания файла с временной метки. Менеджером пакетов, использующим этот подход, является install-log.

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

При таком подходе, записываются команды, выполняемые сценариями установки. Есть два метода, которые можно использовать:

Переменная среды LD_PRELOAD может быть установлена так, чтобы она указывала на библиотеку, которую нужно предварительно загрузить перед установкой. Во время установки эта библиотека отслеживает устанавливаемые пакеты, присоединяясь к различным исполняемым файлам, таким как cp, install, mv, и отслеживая системные вызовы, изменяющие файловую систему. Чтобы этот подход работал, все исполняемые файлы должны быть динамически связаны без битов suid или sgid. Предварительная загрузка библиотеки может вызвать некоторые нежелательные побочные эффекты во время установки. Поэтому рекомендуется выполнить некоторые тесты, чтобы убедиться, что менеджер пакетов ничего не сломает и что он регистрирует все соответствующие файлы.

Другой метод заключается в использовании strace, который регистрирует все системные вызовы, сделанные во время выполнения сценариев установки.

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

Этот подход используется большинством менеджеров пакетов, имеющихся в коммерческих дистрибутивах. Примерами менеджеров пакетов, которые следуют этому подходу, являются RPM (который, кстати, требуется согласно спецификации Linux Standard Base Specification), pkg-utils, apt Debian и система Portage Gentoo. Описание того, как использовать этот стиль управления пакетами для систем LFS, находится по адресу https://mirror.linuxfromscratch.ru/hints/downloads/files/fakeroot.txt.

Создание файлов пакетов, содержащих информацию о зависимостях, является сложной задачей и выходит за рамки LFS.

Slackware использует систему на основе tar для архивов пакетов. Эта система намеренно не обрабатывает зависимости пакетов, как это делают более сложные менеджеры пакетов. Подробнее об управлении пакетами Slackware см. https://www.slackbook.org/html/package-management.html.

Эта схема, уникальная для LFS, была разработана Маттиасом Бенкманом и доступна в проекте Hints. В этой схеме каждый пакет устанавливается отдельным пользователем в стандартные папки. Файлы, принадлежащие пакету, легко идентифицируются путем проверки идентификатора пользователя. Особенности и недостатки этого подхода слишком сложны, чтобы описывать их в этом разделе. Для получения более подробной информации, пожалуйста, ознакомьтесь с советами по адресу https://mirror.linuxfromscratch.ru/hints/downloads/files/more_control_and_pkg_man.txt.

Одним из преимуществ системы LFS является отсутствие файлов, зависящих от положения файлов на диске. Клонировать сборку LFS на другой компьютер с той же архитектурой, что и у базовой системы, так же просто, как использовать tar для архивации раздела LFS, содержащем корневой каталог (около 900 МБ в несжатом виде для базовой сборки LFS), скопировать этот файл по сети или с помощью CD / USB носителя в новую систему и распаковать его. После этого необходимо изменить несколько конфигурационных файлов. Файлы, которые, возможно, потребуется изменить представлены в списке ниже: /etc/hosts, /etc/fstab, /etc/passwd, /etc/group, /etc/shadow, и /etc/ld.so.conf.

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

Наконец, новую систему необходимо сделать загрузочной так, как это описано в Разделе 10.4. «Использование GRUB для настройки процесса загрузки»

Удалите две справочные страницы для функций хэширования паролей. Libxcrypt предоставит улучшенную версию этих справочных страниц:

#!/bin/bash
SRC_FILE=man-pages-6.06.tar.xz
SRC_FOLDER=man-pages-6.06

tar -xvf $SRC_FILE&&
cd $SRC_FOLDER&&
rm -v man3/crypt*&&
make prefix=/usr install&&
cd .. &&
rm -rf $SRC_FOLDER &&
echo Delete $SRC_FOLDER
echo Ok $SRC_FILE

Установите пакет Man-pages выполнив команду: make prefix=/usr install

Краткое описание

Для этого пакета необходимо лишь скопировать нужные файлы:

#!/bin/bash
SRC_FILE=iana-etc-20240125.tar.gz
SRC_FOLDER=iana-etc-20240125
tar -xvf $SRC_FILE&&
cd $SRC_FOLDER&&
cp services protocols /etc*&&
cd .. &&
rm -rf $SRC_FOLDER &&
echo Delete $SRC_FOLDER
echo Ok $SRC_FILE

Краткое описание

Некоторые программы Glibc используют не совместимый с FHS каталог /var/db для хранения своих данных во время выполнения. Примените следующий патч, чтобы эти программы хранили свои данные в каталогах, совместимых с FHS:

patch -Np1 -i ../glibc-2.39-fhs-1.patch

Документация Glibc рекомендует выполнять компиляцию в отдельном каталоге:

mkdir -v build
cd       build

Убедитесь, что утилиты ldconfig и sln будут установлены в /usr/sbin:

echo "rootsbindir=/usr/sbin" > configparms

Подготовьте Glibc к компиляции:

../configure --prefix=/usr                            \
             --disable-werror                         \
             --enable-kernel=4.19                     \
             --enable-stack-protector=strong          \
             --disable-nscd                           \
             libc_cv_slibdir=/usr/lib

• –disable-werror

Отключает параметр -Werror, передаваемый GCC. Это необходимо для запуска набора тестов.

• –enable-kernel=4.19

Этот параметр сообщает системе сборки, что Glibc может использоваться с ядрами старше 4.19. Это значение используется для создание обходных путей на случай, если системный вызов, представленный в более поздней версии, нельзя будет использовать.

• –enable-stack-protector=strong

Этот параметр повышает безопасность системы за счет добавления дополнительного кода для проверки переполнения буфера. Обратите внимание, что Glibc всегда явно переопределяет параметры GCC по умолчанию, поэтому необходимо всегда указывать эту опцию, несмотря на то, что мы уже указали –enable-default-ssp для GCC.

• –disable-nscd

Параметр отключает сборку демона кэша службы имен, который больше не используется.

• libc_cv_slibdir=/usr/lib

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

Скомпилируйте пакет:

make

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

make check

Вы можете увидеть, что ряд тестов завершились неудачей. Набор тестов Glibc в некоторой степени зависит от хост-системы. Несколько ошибок из более чем 5000 тестов можно игнорировать. Список наиболее распространенных проблем последних версий LFS:

• Известно, что io/tst-lchmod не работает в среде chroot LFS.
• Известно, что некоторые тесты, например nss/tst-nss-files-hosts-multi и nptl/tst-thread-affinity завершаются неудачей из-за тайм-аута (особенно когда система работает относительно медленно и/или набор тестов запущен в несколько потоков). Эти тесты могут быть идентифицированы с помощью следующей команды:

grep "Timed out" -l $(find -name \*.out)

Можно повторно запустить отдельный тест, увеличив таймаут с помощью команды TIMEOUTFACTOR=< class=""> make test t=<test name>. Например, TIMEOUTFACTOR=10 make test t=nss/tst-nss-files-hosts-multi перезапустит nss/tst-nss-files-hosts-multi, увеличив начальный таймаут в 10 раз.

• Кроме того, некоторые тесты могут завершиться неудачно при использовании относительно старой модели процессора (например, elf/tst-cpu-features-cpuinfo) или версии ядра хоста (например, stdlib/tst-arc4random-thread).

На этапе установки Glibc будет жаловаться на отсутствие файла /etc/ld.so.conf, хотя это безобидное сообщение, предотвратить его появление можно с помощью команды:

touch /etc/ld.so.conf

Исправьте Makefile, чтобы пропустить устаревшую проверку работоспособности, которая завершается неудачей в современной конфигурации Glibc:

sed '/test-installation/s@$(PERL)@echo not running@' -i ../Makefile

rm -f /usr/sbin/nscd

systemctl disable --now nscd

make DESTDIR=$PWD/dest install
install -vm755 dest/usr/lib/*.so.* /usr/lib

Установите пакет:

make install

Исправьте жестко заданный путь к исполняемому загрузчику в скрипте ldd:

sed '/RTLDLIST=/s@/usr@@g' -i /usr/bin/ldd

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

Отдельные локали можно установить с помощью программы localedef. Например, вторая команда localedef приведенная ниже, объединяет определение независимой от набора символов локали /usr/share/i18n/locales/cs_CZ с набором символов /usr/share/i18n/charmaps/UTF-8.gz и добавляет результат в файл /usr/lib/locale/locale-archive. Следующие инструкции установят минимальный набор локалей, необходимый для оптимального охвата тестов

mkdir -pv /usr/lib/locale
localedef -i C -f UTF-8 C.UTF-8
localedef -i cs_CZ -f UTF-8 cs_CZ.UTF-8
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i de_DE -f UTF-8 de_DE.UTF-8
localedef -i el_GR -f ISO-8859-7 el_GR
localedef -i en_GB -f ISO-8859-1 en_GB
localedef -i en_GB -f UTF-8 en_GB.UTF-8
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i en_US -f UTF-8 en_US.UTF-8
localedef -i es_ES -f ISO-8859-15 es_ES@euro
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fa_IR -f UTF-8 fa_IR
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i fr_FR -f UTF-8 fr_FR.UTF-8
localedef -i is_IS -f ISO-8859-1 is_IS
localedef -i is_IS -f UTF-8 is_IS.UTF-8
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i it_IT -f ISO-8859-15 it_IT@euro
localedef -i it_IT -f UTF-8 it_IT.UTF-8
localedef -i ja_JP -f EUC-JP ja_JP
localedef -i ja_JP -f SHIFT_JIS ja_JP.SJIS 2> /dev/null || true
localedef -i ja_JP -f UTF-8 ja_JP.UTF-8
localedef -i nl_NL@euro -f ISO-8859-15 nl_NL@euro
localedef -i ru_RU -f KOI8-R ru_RU.KOI8-R
localedef -i ru_RU -f UTF-8 ru_RU.UTF-8
localedef -i se_NO -f UTF-8 se_NO.UTF-8
localedef -i ta_IN -f UTF-8 ta_IN.UTF-8
localedef -i tr_TR -f UTF-8 tr_TR.UTF-8
localedef -i zh_CN -f GB18030 zh_CN.GB18030
localedef -i zh_HK -f BIG5-HKSCS zh_HK.BIG5-HKSCS
localedef -i zh_TW -f UTF-8 zh_TW.UTF-8

Кроме того, установите локаль для вашей страны, языка и набора символов.

В качестве альтернативы, установите сразу все локали перечисленные в файле glibc-2.39/localedata/SUPPORTED (он включает все локали из списка выше и многие другие), выполнив команду:

make localedata/install-locales

Затем используйте команду localedef для создания и установки локалей, не перечисленных в файле glibc-2.39/localedata/SUPPORTED, когда они вам понадобятся. Например, для некоторых тестов в этой главе потребуются следующие две локали:

localedef -i C -f UTF-8 C.UTF-8
localedef -i ja_JP -f SHIFT_JIS ja_JP.SJIS 2> /dev/null || true

Необходимо создать файл /etc/nsswitch.conf, потому что настроенный по умолчанию Glibc плохо работает в сетевой среде.

Создайте новый фай /etc/nsswitch.conf, выполнив следующие действия:

cat > /etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf

passwd: files systemd
group: files systemd
shadow: files systemd

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

# End /etc/nsswitch.conf
EOF

Установите и настройте часовой пояс следующим образом:

tar -xf ../../tzdata2024a.tar.gz

ZONEINFO=/usr/share/zoneinfo
mkdir -pv $ZONEINFO/{posix,right}

for tz in etcetera southamerica northamerica europe africa antarctica  \
          asia australasia backward; do
    zic -L /dev/null   -d $ZONEINFO       ${tz}
    zic -L /dev/null   -d $ZONEINFO/posix ${tz}
    zic -L leapseconds -d $ZONEINFO/right ${tz}
done

cp -v zone.tab zone1970.tab iso3166.tab $ZONEINFO
zic -d $ZONEINFO -p America/New_York
unset ZONEINFO

• zic -L /dev/null …

Создаёт часовые пояса posix без секунд координации. Обычно их помещают как в zoneinfo так и в zoneinfo/posix. Часовые пояса POSIX должны быть прописаны в zoneinfo, иначе различные тесты будут сообщать об ошибках. На встраиваемых системах с небольшим диском, где часовые пояса никогда не будут обновляться, можно сэкономить примерно 1.9 MB не используя каталог posix, однако некоторые приложения или наборы тестов могут вызывать сбои.

• zic -L leapseconds …

Создаёт правильные часовые пояса с секундами координации. На встраиваемых системах с небольшим диском, где часовые пояса никогда не будут обновляться, а правильность времени неважна, можно выиграть примерно 1.9 MB, исключив каталог right.

• zic … -p …

Создаёт файл posixrules. Используется New York, потому что POSIX требует, чтобы правила перехода на летнее время соответствовали правилам США.

Один из способов определить местный часовой пояс — запустить следующий скрипт:

tzselect

После нескольких вопросов о местоположении скрипт выдаст наименование часового пояса (например America/Edmonton). В файле /usr/share/zoneinfo перечислены и другие возможные часовые пояса, такие как Canada/Eastern или EST5EDT, которые не распознаются скриптом, но могут быть использованы.

Создайте файл /etc/localtime выполнив:

ln -sfv /usr/share/zoneinfo/<xxx> /etc/localtime

Замените <xxx> на имя выбранного часового пояса (например, Europe/Moscow).

По умолчанию, динамический загрузчик (/lib/ld-linux.so.2) ищет в каталоге /usr/lib, нужные для работы программ библиотеки. Однако, если библиотеки находятся в другом каталоге, то его необходимо указать в файле /etc/ld.so.conf, чтобы динамический загрузчик мог их найти. Два каталога - /usr/local/lib и /opt/lib часто используются для дополнительных библиотек, поэтому добавьте их в пути поиска для динамического загрузчика.

Создайте новый файл /etc/ld.so.conf выполнив:

cat > /etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf
/usr/local/lib
/opt/lib

EOF

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

cat >> /etc/ld.so.conf << "EOF"
# Add an include directory
include /etc/ld.so.conf.d/*.conf

EOF
mkdir -pv /etc/ld.so.conf.d

Краткое описание

#!/bin/bash
SRC_FILE=glibc-2.39.tar.xz
SRC_FOLDER=glibc-2.39

tar -xvf $SRC_FILE
cd $SRC_FOLDER

patch -Np1 -i ../glibc-2.39-fhs-1.patch &&

mkdir -v build &&
cd       build &&

echo "rootsbindir=/usr/sbin" > configparms &&

time {
../configure --prefix=/usr                            \
             --disable-werror                         \
             --enable-kernel=4.19                     \
             --enable-stack-protector=strong          \
             --disable-nscd                           \
             libc_cv_slibdir=/usr/lib && 
make && 
make check && 
touch /etc/ld.so.conf && 
sed '/test-installation/s@$(PERL)@echo not running@' -i ../Makefile && 
make install && 
sed '/RTLDLIST=/s@/usr@@g' -i /usr/bin/ldd; } && 
mkdir -pv /usr/lib/locale && 
localedef -i C -f UTF-8 C.UTF-8
localedef -i cs_CZ -f UTF-8 cs_CZ.UTF-8
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i de_DE -f UTF-8 de_DE.UTF-8
localedef -i el_GR -f ISO-8859-7 el_GR
localedef -i en_GB -f ISO-8859-1 en_GB
localedef -i en_GB -f UTF-8 en_GB.UTF-8
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i en_US -f UTF-8 en_US.UTF-8
localedef -i es_ES -f ISO-8859-15 es_ES@euro
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fa_IR -f UTF-8 fa_IR
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i fr_FR -f UTF-8 fr_FR.UTF-8
localedef -i is_IS -f ISO-8859-1 is_IS
localedef -i is_IS -f UTF-8 is_IS.UTF-8
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i it_IT -f ISO-8859-15 it_IT@euro
localedef -i it_IT -f UTF-8 it_IT.UTF-8
localedef -i ja_JP -f EUC-JP ja_JP
localedef -i ja_JP -f SHIFT_JIS ja_JP.SJIS 2> /dev/null || true
localedef -i ja_JP -f UTF-8 ja_JP.UTF-8
localedef -i nl_NL@euro -f ISO-8859-15 nl_NL@euro
localedef -i ru_RU -f KOI8-R ru_RU.KOI8-R
localedef -i ru_RU -f UTF-8 ru_RU.UTF-8
localedef -i se_NO -f UTF-8 se_NO.UTF-8
localedef -i ta_IN -f UTF-8 ta_IN.UTF-8
localedef -i tr_TR -f UTF-8 tr_TR.UTF-8
localedef -i zh_CN -f GB18030 zh_CN.GB18030
localedef -i zh_HK -f BIG5-HKSCS zh_HK.BIG5-HKSCS
localedef -i zh_TW -f UTF-8 zh_TW.UTF-8
cat > /etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf

passwd: files systemd
group: files systemd
shadow: files systemd

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

# End /etc/nsswitch.conf
EOF
tar -xf ../../tzdata2024a.tar.gz
ZONEINFO=/usr/share/zoneinfo
mkdir -pv $ZONEINFO/{posix,right}
for tz in etcetera southamerica northamerica europe africa antarctica  \
          asia australasia backward; do
    zic -L /dev/null   -d $ZONEINFO       ${tz}
    zic -L /dev/null   -d $ZONEINFO/posix ${tz}
    zic -L leapseconds -d $ZONEINFO/right ${tz}
done
cp -v zone.tab zone1970.tab iso3166.tab $ZONEINFO
zic -d $ZONEINFO -p America/New_York
unset ZONEINFO
ln -sfv /usr/share/zoneinfo/Europe/Moscow /etc/localtime
cat > /etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf
/usr/local/lib
/opt/lib

EOF
cat >> /etc/ld.so.conf << "EOF"
# Add an include directory
include /etc/ld.so.conf.d/*.conf

EOF
mkdir -pv /etc/ld.so.conf.d
cd ../.. &&
rm -rf $SRC_FOLDER &&
echo Delete $SRC_FOLDER
echo Ok $SRC_FILE

Подготовьте Zlib к компиляции:

./configure --prefix=/usr

Скомпилируйте пакет:

make

Чтобы протестировать пакет, выполните:

make check

Удалите бесполезную статическую библиотеку:

rm -fv /usr/lib/libz.a

Краткое описание

Примените патч, который установит документацию для этого пакета:

patch -Np1 -i ../bzip2-1.0.8-install_docs-1.patch

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

sed -i 's@\(ln -s -f \)$(PREFIX)/bin/@\1@' Makefile

Убедитесь, что справочные страницы установлены в правильном месте:

sed -i "s@(PREFIX)/man@(PREFIX)/share/man@g" Makefile

Подготовьте Bzip2 к компиляции:

make -f Makefile-libbz2_so
make clean

Значение параметра make:

• -f Makefile-libbz2_so

Этот параметр позволяет выполнить сборку, с использованием другого Makefile, в данном случае Makefile-libbz2_so, который создает динамическую библиотеку libbz2.so и связывает с ней Bzip2.

Скомпилируйте и протестируйте пакет:

make

Установите пакет:

make PREFIX=/usr install

Установите библиотеку:

cp -av libbz2.so.* /usr/lib
ln -sv libbz2.so.1.0.8 /usr/lib/libbz2.so

Установите общий бинарный файл bzip2 в каталог /usr/bin, и замените две копии bzip2 символическими ссылками:

cp -v bzip2-shared /usr/bin/bzip2
for i in /usr/bin/{bzcat,bunzip2}; do
  ln -sfv bzip2 $i
done

Удалите ненужную статическую библиотеку:

rm -fv /usr/lib/libbz2.a

Краткое описание

Подготовьте Xz к компиляции:

./configure --prefix=/usr    \
            --disable-static \
            --docdir=/usr/share/doc/xz-5.4.6

Скомпилируйте пакет:

make

Чтобы протестировать пакет, выполните:

make check

Установите пакет:

make install

Краткое описание

Скомпилируйте пакет:

make prefix=/usr

Чтобы протестировать пакет, выполните:

make check

Установите пакет:

make prefix=/usr install

Удалите статическую библиотеку:

rm -v /usr/lib/libzstd.a

Краткое описание

Подготовьте File к компиляции:

./configure --prefix=/usr

Скомпилируйте пакет:

make

Чтобы протестировать пакет, выполните:

make check

Установите пакет:

make install

Краткое описание

Переустановка пакета Readline приводит к перемещению старых библиотек в <libraryname>.old. Обычно это не вызывает проблем, но в некоторых случаях могут возникать ошибки линковки с ldconfig. Этого можно избежать, выполнив следующие две команды sed:

sed -i '/MV.*old/d' Makefile.in
sed -i '/{OLDSUFF}/c:' support/shlib-install

Теперь устраните проблему, выявленную разработчиками:

patch -Np1 -i ../readline-8.2-upstream_fixes-3.patch

Подготовьте Readline к компиляции:

./configure --prefix=/usr    \
            --disable-static \
            --with-curses    \
            --docdir=/usr/share/doc/readline-8.2

• –with-curses

Этот параметр сообщает Readline, что он может найти функции библиотеки termcap в библиотеке curses, а не в отдельной библиотеке termcap. Это позволит сгенерировать корректный файл readline.pc.

Скомпилируйте пакет:

make SHLIB_LIBS="-lncursesw"

• SHLIB_LIBS=«-lncursesw»

Этот параметр принудительно линкует Readline с библиотекой libncursesw.

С этим пакетом не поставляется набор тестов.

Установите пакет:

make SHLIB_LIBS="-lncursesw" install

По желанию установите документацию:

install -v -m644 doc/*.{ps,pdf,html,dvi} /usr/share/doc/readline-8.2

Краткое описание

Подготовьте M4 к компиляции:

./configure --prefix=/usr

Скомпилируйте пакет:

make

Чтобы протестировать пакет, выполните:

make check

Установите пакет:

make install

Краткое описание

Подготовьте Bc к компиляции:

CC=gcc ./configure --prefix=/usr -G -O3 -r

• CC=gcc

Этот параметр определяет используемый компилятор

• -G

Пропускает часть тестов, которые не будут работать, пока не будет установлена программа bc.

• -O3

Указывает используемый уровень оптимизации.

• -r

Включает использование Readline для улучшения функции редактирования строк в bc.

Скомпилируйте пакет:

make

Чтобы протестировать bc, запустите:

make check

Установите пакет:

make install

Краткое описание