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

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Подготовка Bash к компиляции:

./configure --prefix=/tools --without-bash-malloc

Значение опций конфигурации:

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

make

Для проверки результата вводим: make tests.

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

make install

Создадим ссылку для программ, которые используют sh в качестве шелла:

ln -s bash /tools/bin/sh

Важно чтобы Binutils был первым из пакетов, которые мы установим, потому что Glibc и GCC проводят некоторые тесты на доступные компоновщик и ассемблер для определения доступных опций.

Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu ). Binutils рекомендуется компилировать с настройками по умолчанию. Если вы задали переменные такие как CFLAGS или CXXFLAGS, изменяющие уровень оптимизации по умолчанию, рекомендуется убрать их при сборке пакета binutils. Изменяя оптимизации для binutils, вы действуете на свой страх и риск.

В документации по Binutils рекомендуется собирать Binutils вне директории с исходниками, в отдельной директории для сборки:

 
mkdir ../binutils-build 
cd ../binutils-build 

Теперь подготовим Binutils к компиляции:

 
../binutils-2.15.91.0.2/configure --prefix=/tools \ 
    --disable-nls 

Описание используемых опций:

Вернемся к компиляции пакета:

 
make configure-host 
make LDFLAGS="-all-static" 

Описание параметров сборки:

Компиляция проведена. Обычно мы запускаем тест, но на этой ранней стадии требуемые для выполнения теста программы (Tcl, Expect и DejaGNU) еще отсутствуют на своем месте. Кроме того, запускать тест на этом этапе сборки нет смысла, т.к. мы скоро заменим binutils на втором шаге.

Устанавливаем пакет

 
make install 

Теперь подготовим компоновщик к последующему "встраиванию" в Glibc на следующей фазе сборки:

 
make -C ld clean 
make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib 

Описание параметров сборки:

Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu ) . Binutils рекомендуется компилировать с настройками по умолчанию. Если вы задали переменные такие как CFLAGS или CXXFLAGS, изменяющие уровень оптимизации по умолчанию, рекомендуется убрать их при сборке пакета binutils. Изменяя оптимизации для binutils, вы действуете на свой страх и риск.

Опять создаем отдельную директорию для сборки:

 
mkdir ../binutils-build 
cd ../binutils-build 

Подготавливаем Binutils для компиляции:

 
../binutils-2.15.91.0.2/configure --prefix=/tools \ 
    --enable-shared --with-lib-path=/tools/lib 

Описание новых используемых опций:

Компилируем пакет

 
make 

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

 
make check 

Устанавливаем пакет

 
make install 

Теперь подготовим Binutils к “переопределению” средств на следующей фазе в следующей главе:

 
make -C ld clean 
make -C ld LIB_PATH=/usr/lib:/lib 

Подготавливаем Bison для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Пакет Bzip2 не содержит скрипта configure. Компилируем его командой:

 
make 

Устанавливаем пакет

 
make PREFIX=/tools install 

Подготавливаем Coreutils для компиляции:

 
DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools 

Успешная компиляция этого пакета будет с версией Glibc старше 2.3.2. Переменная окружения DEFAULT_POSIX2_VERSION, равная “199209”, обеспечивает обратную совместимость с предыдущими версиями Coreutils.

Компилируем пакет

 
make 

Для проверки результата вводим: make RUN_EXPENSIVE_TESTS=yes check.

RUN_EXPENSIVE_TESTS=yes заставит запустить некоторые дополнительные тесты, которые требуют достаточно много времени на некоторых платформах. Тем не менее, это не проблема для Linux.

Устанавливаем пакет

 
make install 

Подготавливаем DejaGNU для компиляции:

 
./configure --prefix=/tools 

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

 
make install 

Подготавливаем Diffutils для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

В этом пакете отсутствуют тесты.

Устанавливаем пакет

make install

Для начала наложим патч, который устранит неисправность в Expect, выдающем неверный результат при тестировании GCC.

 
patch -Np1 -i ../expect-5.42.1-spawn-1.patch 

Теперь подготавливаем Expect для компиляции:

 
./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no 

Описание опций конфигурации:

Соберем пакет:

 
make 

Для проверки результата вводим: make test. Тестирование Expect известно своими ошибками из-за влияния основной системы. Таким образом отрицательные результаты тестов не будут здесь сюрпризом и не являются критичными.

Устанавливаем пакет

 
make SCRIPTS="" install 

Описание параметров сборки:

Теперь вы можете удалить директории с исходниками Tcl и Expect.

Подготавливаем Findutils для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Flex имеет несколько известных проблем, которые могут быть исправлены следующим патчем:

patch -Np1 -i ../flex-2.5.31-debian_fixes-2.patch

GNU autotools определит, что исходный код Flex был изменен предыдущим патчем и, соответственно, попытается обновить страницы документации. Это не работает на многих системах и основная страница остается неизменной, поэтому подтверждаем, что она не была изменена:

touch doc/flex.1

Теперь подготавливаем Flex для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Подготавливаем Gawk для компиляции:

 
./configure --prefix=/tools 

Компилируем пакет

 
make 

Для проверки результата (не обязательно), выполняем: make check.

Устанавливаем пакет

 
make install 

Распакуйте только тарбол GCC-core, нам пока не нужен компилятор C++.

Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu). GCC рекомендуется компилировать с настройками по умолчанию. Если вы задали переменные такие как CFLAGS и CXXFLAGS, рекомендуется убрать их при сборке пакета GCC.

В документации по GCC рекомендуется собирать GCC вне директории с исходниками в отдельной директории для сборки:

 
mkdir ../gcc-build 
cd ../gcc-build 

Подготавливаем GCC для компиляции:

 
../gcc-3.4.1/configure --prefix=/tools \ 
    --libexecdir=/tools/lib --with-local-prefix=/tools \ 
    --disable-nls --enable-shared --enable-languages=c 

Описание опций конфигурации:

Продолжим компиляцию пакета:

 
make BOOT_LDFLAGS="-static" bootstrap 

Описание параметров сборки:

Компиляция проведена. На этом этапе обычно выполняется тест, но как было сказано ранее, мы еще не имеем полного набора тестовых утилит на своем месте. Кроме того, смысл запуска теста на этом этапе минимален т.к. программы, собранные на этом шаге скоро будут заменены.

Устанавливаем пакет

 
make install 

Многие программы и скрипты используют cc вместо gcc для обеспечения переносимости программ на все Unix системы. Не у всех установлен именно компилятор GNU C. Запуск cc позволяет администратору выбирать, какой компилятор C устанавливать в систему, и мы создаем ссылку на него:

 
ln -s gcc /tools/bin/cc 

Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu). GCC рекомендуется компилировать с настройками по умолчанию. Если вы задали переменные такие как CFLAGS и CXXFLAGS, рекомендуется убрать их при сборке пакета GCC.

Средства, необходимые для тестирования GCC и Binutils, теперь установлены (Tcl, Expect и DejaGnu). Мы можем вернуться к пересборке GCC и Binutils, соединить их с новым Glibc и правильно их протестировать. Но есть одно замечание: тестирование сильно зависит от правильного функционирования псевдо терминалов (PTY) из основной системы. На данный момент PTY осуществляется с помощью файловой системы devpts. Вы можете быстро проверить правильность установки системы командой:

 
expect -c "spawn ls" 

Если вы получили ответ:

 
The system has no more ptys.   
Ask your system administrator to create more. 

Ваш основной дистрибутив не поддерживает операции PTY. В этом случае здесь не место запуску тестирования для GCC и Binutils и вы можете пропустить его. Вы можете проконсультироваться в LFS Wiki на http://wiki.linuxfromscratch.org/ для более подробной информации о работе с PTY.

Распакуйте все три тарбола GCC (-core, -g++ и -testsuite) в одной рабочей директории. Они распакуются в одну общую поддиректорию gcc-3.4.1/

Для начала исправим одну проблему и создадим необходимую сборку:

 
patch -Np1 -i ../gcc-3.4.1-no_fixincludes-1.patch 
patch -Np1 -i ../gcc-3.4.1-specs-1.patch 

Первый патч отключит скрипт GCC fixincludes. Мы расскажем об этом вкратце, не вдаваясь в подробности. При нормальных обстоятельствах скрипт GCC fixincludes сканирует вашу систему на файлы заголовков Glibc, нуждающиеся в исправлении, исправляет их и переносит их в директорию включений для GCC. В Главе 6, после установки нового Glibc, эта директория будет найдена, в результате чего GCC найдет заголовки основной системы и мы не сможем корректно использовать Glibc в системе LFS.

Второй патч изменяет расположение по умолчанию для динамического компоновщика GCC (обычно ld-linux.so.2). Он также удаляет /usr/include из пути для поиска GCC. Пропатчивание spec-файла сейчас позволит убедиться, что собираемый GCC будет использовать наш новый динамический компоновщик. То есть, наши окончательные (и временные) бинарники будут скомпонованы с новым Glibc.

Создайте отдельную директорию для сборки и перейдите в нее:

 
mkdir ../gcc-build 
cd ../gcc-build 

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

Теперь подготавливаем GCC для компиляции:

 
../gcc-3.4.1/configure --prefix=/tools \ 
    --libexecdir=/tools/lib --with-local-prefix=/tools \ 
    --enable-clocale=gnu --enable-shared \ 
    --enable-threads=posix --enable-__cxa_atexit \ 
    --enable-languages=c,c++ --disable-libstdcxx-pch 

Описание новых опций конфигурации:

Компилируем пакет

 
make 

Здесь нет необходимости использовать bootstrap, так как мы компилируем этот GCC с помощью той же самой версии GCC, но установленой ранее.

Компиляция проведена. Как было сказано ранее, запуск теста для временной сборки в этой части проводить не обязательно. В любом случае, для запуска теста GCC используйте следующую команду:

 
make -k check 

Флаг -k используется для того, чтобы тестирование не прекратилось после первого отрицательного результата, а проводило дальнейшие тесты. Тестирование GCC довольно исчерпывающее, и поэтому мы практически гарантировано получим пару отрицательных результатов тестов. Для просмотра результатов тестирования выполните команду:

 
../gcc-3.4.1/contrib/test_summary | more 

Вы можете сравнить ваши результаты с результатами из списка рассылки для того, чтобы найти аналогичные вашим. К примеру, посмотреть результаты тестирования GCC-3.3.1 на i686-pc-linux-gnu можно на http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html.

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

Устанавливаем пакет

 
make install 

Подготавливаем Gettext для компиляции:

./configure --prefix=/tools --disable-libasprintf \
    --disable-csharp

Описание опций конфигурации:

Компилируем пакет

make

Для проверки результата вводим: make check.

Тестирование Gettext занимает много времени, около 7 SBU. Тестирование Gettext в этой главе может не пройти успешно из-за зависимостей от основной системы - к примеру, если будет найден компилятор Java. Экспериментальный патч, исключающий Java, доступен в проэкте LFS Patches на http://www.linuxfromscratch.org/patches/.

Устанавливаем пакет

make install

Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu). Если вы задали переменные окружения, такие как CFLAGS и CXXFLAGS, рекомендуется убрать их при сборке Glibc.

Изменяя флаги оптимизации для glibc, вы действуете на свой страх и риск.

Документация по Glibc рекомендует собирать Glibc вне директории с исходниками, в отдельной директории для сборки:

 
mkdir ../glibc-build 
cd ../glibc-build 

Далее, подготовим Glibc к компиляции:

 
../glibc-2.3.4-20040701/configure --prefix=/tools \ 
    --disable-profile --enable-add-ons=nptl --with-tls \ 
    --with-__thread --enable-kernel=2.6.0 \ 
    --with-binutils=/tools/bin --without-gd --without-cvs \ 
    --with-headers=/tools/glibc-kernheaders 

Описание опций конфигурации:

На этом шаге вы можете увидеть следующее предупреждение:

Отсутствующая или несовместимая программа msgfmt безвредна, но может привести к определенным проблемам при тестировании. Эта программа msgfmt является частью пакета Gettext, который используется из дистрибутива основной системы. Если msgfmt имеется, но считается несовместимой, обновите пакет Gettext из основной системы или продолжайте без него.

Компилируем пакет

 
make 

Компиляция проведена. Как было сказано ранее, запуск теста для временной сборки в этой части проводить не обязательно. В любом случае, для запуска теста Glibc используйте следующую команду:

 
make check 

Для обсуждения особо выжных ошибок тестирования, смотрите Раздел 6.11, “Glibc-2.3.4-20040701.”

В этой части некоторые тесты могут быть неспособны дать положительный результат при использовании имеющихся приложений или переменных окружения базовой системы. Ошибки тестов Glibc в этой части, обычно, не должны беспокоить. Glibc, проинсталированные в Главе 6, будут полностью готовы к использованию. Но имейте в виду, что при прохождении тестов (даже в Главе 6), некоторые ошибки все еще могут появляться, например в тесте math.

Когда вы получите сообщение о непрохождении теста, запомните его, а затем продолжите тестирование дальше, опять выполнив команду make check. Скрипт тестирования запоминает пройденые тесты для возможности его продолжения после выхода из-за ошибки. Вы можете использовать эту возможность "запуска-остановки" автоматически с помощью команды make -k check. Если вы так сделаете, проверьте логи тестирования и посмотрите общее количество и причины проваленных тестов.

Этап инсталляции Glibc будет иметь предупреждение в конце об отсутствии /tools/etc/ld.so.conf. Упредим это сообщение:

 
mkdir /tools/etc 
touch /tools/etc/ld.so.conf 

Устанавливаем пакет

 
make install 

Разные страны и культуры имеют различные соглашения для коммуникаций. Эти соглашения состоят как из очень простых, таких как форматы даты и времени, так и из более сложных, таких как разговорный язык. “Интернационализация” программ GNU работает с помощью локалей (locales).

Для установки Glibc локалей в любом случае,используйте следующую команду:

 
make localedata/install-locales 

Альтернативой запуску предыдущей команды для экономии времени является установка только определенных локалей, тех которые вам нужны. Это может быть достигнуто использованием команды localedef command. Информацию об использовании этой команды можно получить из файла INSTALL в исходниках Glibc. Тем не менее, список локалей может быть существенным для некоторых тестов, в частности, теста libstdc++ из GCC. Следующие команды, используемые вместо вышеописаной install-locales установят минимальный набор локалей для успешного завершения тестирований:

 
mkdir -p /tools/lib/locale 
localedef -i de_DE -f ISO-8859-1 de_DE 
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro 
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 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 it_IT -f ISO-8859-1 it_IT 
localedef -i ja_JP -f EUC-JP ja_JP 

Подготавливаем Grep для компиляции:

./configure --prefix=/tools \
    --disable-perl-regexp --with-included-regex

Описание параметров конфигурации:

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Подготавливаем Gzip для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

В пакете отсутствует тест сборки.

Устанавливаем пакет

make install

Подготавливаем Make для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Подготавливаем Patch для компиляции:

CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools

Флаг препроцессора -D_GNU_SOURCE нужен только на платформах PowerPC. На других платформах вы можете его пропустить.

Компилируем пакет

make

Устанавливаем пакет

make install

Подготавливаем Sed для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Подготавливаем Tar для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Подготавливаем Texinfo для компиляции:

./configure --prefix=/tools

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

Util-linux не может использовать заголовки и библиотеки из директории /tools. Это исправляется с помощью исправления скрипта конфигурации:

sed -i 's@/usr/include@/tools/include@g' configure

Подготавливаем Util-linux для компиляции:

./configure

Скомпилируем поддержку некоторых шаблонов:

make -C lib

И поскольку нам нужны только некоторые из утилит этого пакета, соберем только их:

make -C mount mount umount
make -C text-utils more

Теперь скопируем эти файлы в директорию временных средств:

cp mount/{,u}mount text-utils/more /tools/bin

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

Подготовимся к установке заголовков:

 
make mrproper 

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

Создадим файл include/linux/version.h:

 
make include/linux/version.h 

Создадим платформо-зависимую ссылку include/asm:

 
make include/asm 

Установим платформо-зависимые файлы заголовков:

 
mkdir /tools/glibc-kernheaders 
cp -HR include/asm /tools/glibc-kernheaders 
cp -R include/asm-generic /tools/glibc-kernheaders 

Установим кросс-платформенные файлы заголовков:

 
cp -R include/linux /tools/glibc-kernheaders 

В течении многих лет было очень практично использовать “сырые” заголовки ядра (прямо из тарбола ядра) в /usr/include. Проэкт Linux-Libc-Headers был разработан для поддержки Application Programming Interface (API) стабильной версии заголовков Linux.

Установим файлы заголовков:

 
cp -R include/asm-i386 /tools/include/asm 
cp -R include/linux /tools/include 

Если ваша архитектура не i386-совместима, применяйте первую команду аккуратно.

Подготавливаем Ncurses для компиляции:

./configure --prefix=/tools --with-shared \
    --without-debug --without-ada --enable-overwrite

Значение опций конфигурации:

Компилируем пакет

make

Устанавливаем пакет

make install

Для начала применим патч для библиотеки C:

patch -Np1 -i ../perl-5.8.5-libc-1.patch

Подготавливаем Perl для компиляции (убедимся,что часть команды 'IO Fcntl POSIX' корректна):

./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'

Описание опций конфигурации:

Скомпилируем только необходимые средства:

make perl utilities

Хотя Perl идет со встроенным тестом, не рекомендуется выполнять его на этом этапе. Только часть Perl была собрана и запуск make test сейчас будет означать, что должен быть собран остаток Perl, но он необязателен на этом этапе. Тест будет запущен в следующей главе.

Теперь скопируем эти средства и их библиотеки:

cp perl pod/pod2man /tools/bin
mkdir -p /tools/lib/perl5/5.8.5
cp -R lib/* /tools/lib/perl5/5.8.5

Этот и следующие два (Expect и DejaGNU) устанавливаемых пакета нужны для работы тестирования GCC и Binutils. Установка этих трех пакетов нужна только для этого, и если вы не хотите тестировать устанавливаемые средства, то можно пропустить эти установки, но мы рекомендуем проверять работоспособность собираемых средств. Даже если тесты не будут выполняться в этой главе, эти пакеты необходимы для запуска тестов в Главе 6.

Подготавливаем Tcl для компиляции:

 
cd unix 
./configure --prefix=/tools 

Соберем пакет:

 
make 

Для проверки результата вводим: TZ=UTC make test. Тестирование Tcl может не завершиться успешно из-за зависимостей от основной системы, которые полностью не понятны. Таким образом, неудачное завершение тестирования здесь не будет сюрпризом и не является критичным. Параметр TZ=UTC установит временную зону в Coordinated Universal Time (UTC), также известную как время по Гринвичу - Greenwich Mean Time (GMT), но только на время работы тестирования. Детальная информация о переменной окружения TZ находится в Главе 7.

Устанавливаем пакет

 
make install 

Создадим необходимую символическую ссылку:

 
ln -s tclsh8.4 /tools/bin/tclsh 

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

sed -i 's@/sbin/udev@/tools/sbin/udev@g' udevstart.c

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

sed -i 's@/etc@/tools/etc@g' etc/udev/udev.conf.in

Компилируем Udev:

make prefix=/tools etcdir=/tools/etc

Устанавливаем пакет

make DESTDIR=/tools udevdir=/dev install

Конфигурация Udev по умолчанию далека от идеала, поэтому проинсталируем здесь LFS-специфичные конфигурационные файлы:

cp ../udev-config-2.permissions \
    /tools/etc/udev/permissions.d/00-lfs.permissions
cp ../udev-config-1.rules /tools/etc/udev/rules.d/00-lfs.rules

Подготавливаем Autoconf для компиляции:

./configure --prefix=/usr

Компилируем пакет

make

Для проверки результата вводим: make check. Проверка занимает около 2 SBU.

Устанавливаем пакет

make install

Подготавливаем Automake для компиляции:

./configure --prefix=/usr

Компилируем пакет

make

Для проверки результата вводим: make check.

Это может занять много времени, около 5 SBU.

Устанавливаем пакет

make install

Следующий патч необходим только если пакет Readline не был установлен, как было предложено. Этот патч устраняет проблему, когда Bash иногда ограничивает количество символов в строке до 33 перед переходом на следующую строку. Если пакет Readline был установлен согласно инструкции, этот патч не нужен так как он уже применен к Readline для решения этой проблемы.

patch -Np1 -i ../bash-3.0-display_wrap-1.patch

Подготавливаем Bash для компиляции:

./configure --prefix=/usr --bindir=/bin \
    --without-bash-malloc --with-installed-readline

Значение опций конфигурации:

Компилируем пакет

make

Для проверки результата вводим: make tests.

Устанавливаем пакет

make install

Запустим только что установленную прогрпмму bash, заменив уже запущенную:

exec /bin/bash --login +h

Этот пакет известен своим нестабильным поведением при компиляции с измененными опциями оптимизации (включая опции -march и -mcpu ) . Binutils рекомендуется компилировать с настройками по умолчанию. Если вы задали переменные такие как CFLAGS или CXXFLAGS, изменяющие уровень оптимизации по умолчанию, рекомендуется убрать их при сборке пакета binutils.

Проверьте, что псевдо терминалы (PTY) работают корректно внутри среды chroot, выполнив. простой тест:

expect -c "spawn ls"

Если вы получили сообщение вида:

The system has no more ptys.  
Ask your system administrator to create more.

то ваша среда chroot не может оперировать PTY. В этом случае вам не стоит запускать тестирование для Binutils и GCC до того, как вы это исправите.

В документации по Binutils рекомендуется собирать Binutils вне директории с исходниками, а в отдельной директории для сборки:

mkdir ../binutils-build
cd ../binutils-build

Подготавливаем Binutils для компиляции:

../binutils-2.15.91.0.2/configure --prefix=/usr \
    --enable-shared

Компилируем пакет

make tooldir=/usr

Обычно, директория со средствами (директория, где располагаются исполняемые файлы) устанавливается в $(exec_prefix)/$(target_alias), где они и располагаются, например, /usr/i686-pc-linux-gnu. Когда мы собираем средства только для своей системы, нам достаточно установить все просто в директорию /usr. Такая установка нужна только в случае использования cross-компиляции (к примеру, компилируем пакет на машине Intel, но нам нужен код для работы на платформе PowerPC).

Проверим результаты:

make check

Устанавливаем пакет

make tooldir=/usr install

Установим заголовки libiberty, которые нужны для некоторых пакетов:

cp ../binutils-2.15.91.0.2/include/libiberty.h /usr/include

Подготавливаем Bison для компиляции:

./configure --prefix=/usr

Компилируем пакет

make

Для проверки результата вводим: make check.

Устанавливаем пакет

make install

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

make -f Makefile-libbz2_so
make clean

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

Компилируем пакет

make

Если потребуется переинсталировать Bzip2, сначала выполните rm -f /usr/bin/bz*, в противном случае последующая команда make install будет с ошибкой.

Проинсталируем программы:

make install

Установим библиотеку bzip2 в директорию /bin, затем создадим необходимые ссылки и удалим старые:

cp bzip2-shared /bin/bzip2
cp -a libbz2.so* /lib
ln -s ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so
rm /usr/bin/{bunzip2,bzcat,bzip2}
ln -s bzip2 /bin/bunzip2
ln -s bzip2 /bin/bzcat

Нормальное функционирование программы uname из этого пакета иногда нарушается, тогда параметр -p всегда возвращает unknown. Следующий патч исправляет это для архитектуры Intel:

patch -Np1 -i ../coreutils-5.2.1-uname-2.patch

Предупредим Coreutils от инсталяции бинарников, которые будут инсталированы позднее в других пакетах:

patch -Np1 -i ../coreutils-5.2.1-suppress_uptime_kill_su-1.patch

Теперь подготавливаем Coreutils для компиляции:

DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/usr

Компилируем пакет

make

Этот пакет поддерживает тестирование для определения корректности сборки. Тем не менее, этот специфический тест использует непревилегированных пользователей и группы, которые пока не определены в нашей простой системе. Поэтому мы создадим фиктивного пользователя и две фиктивные группы для корректной работы тестов. Если вы не хотите запускать тестирование, то переходите к “установке пакета”.

Создадим фиктивных пользователя и группы:

echo "dummy1:x:1000:" >> /etc/group
echo "dummy2:x:1001:dummy" >> /etc/group
echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd

Теперь тест полностью подготовлен к запуску. Следующий тест проверит запуск от имени пользователя root:

make NON_ROOT_USERNAME=dummy check-root

Следующий тест проверит запуск от имени фиктивного пользователя dummy:

src/su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"

После окончания теста удалим фиктивные группы и пользователя:

sed -i '/dummy/d' /etc/passwd /etc/group

Устанавливаем пакет

make install

И переместим некоторые программы в их правильное место:

mv /usr/bin/{[,basename,cat,chgrp,chmod,chown,cp,dd,df} /bin
mv /usr/bin/{date,echo,false,head,hostname,install,ln} /bin
mv /usr/bin/{ls,mkdir,mknod,mv,pwd,rm,rmdir,sync} /bin
mv /usr/bin/{sleep,stty,test,touch,true,uname} /bin
mv /usr/bin/chroot /usr/sbin

И, наконец, создадим необходимые ссылки для FHS-совместимости:

ln -s ../../bin/install /usr/bin

Подготавливаем Diffutils для компиляции:

./configure --prefix=/usr

Компилируем пакет

make

В этом пакете отсутствуют тесты.

Устанавливаем пакет

make install

Рекомендуется собирать E2fsprogs вне директории с исходниками:

mkdir build
cd build

Подготавливаем E2fsprogs для компиляции:

../configure --prefix=/usr --with-root-prefix="" \
    --enable-elf-shlibs --disable-evms

Описание параметров конфигурации:

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

make

Для проверки результата вводим:

make check

Инсталируем большинство программ:

make install

Инсталируем разделяемые библиотеки:

make install-libs