Установка GCC-3.3.1 - Шаг 2

Ожидаемое время сборки: 11.0 SBU
Ожидаемое место на диске: 274 MB

Переустановка GCC

Средства, необходимые для тестирования GCC и Binutils, теперь установлены (Tcl, Expect и DejaGnu). Мы можем вернуться к пересборке GCC и Binutils, соединить их с новым Glibc и правильно их протестировать. Но есть одно замечание, тестирование сильно зависит от правильного функционирования терминалов pseudo (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.3.1/.

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

patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch
patch -Np1 -i ../gcc-3.3.1-specs-2.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.3.1/configure --prefix=/tools \
--with-local-prefix=/tools \
--enable-clocale=gnu --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-languages=c,c++

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

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

make

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

Замечание: Запуск тестирования здесь не настолько важен, как в Главе 6.

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

make -k check

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

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

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

Проверите, чтобы в результатах были:

* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++

Неожиданным прохождением тест для g++ обязан использованию --enable-__cxa_atexit. Но не все платформы поддерживающие  GCC поддерживают также "__cxa_atexit" в своих библиотеках C, поэтому этот тест не всегда может пройти..

26 неожиданных успешных тестов libstdc++ обязаны использованию --enable-clocale=gnu, которая корректирует выбор на Glibc-based системах версий 2.2.5 и выше. Поддержка основных локалей в библиотеке GNU C важнее, в противном случае выбирается "общая" модель (которая может быть преминима в случаях использования Newlibc, Sun-libc или других libc). Тестирование libstdc++ в случае применения "основной" модели для тестов и не всегда может пройти успешно.

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

Наконец установим пакет:

make install

Замечание: В этом месте рекомендуется повторить простой тест, описаный ранееВернитесь к части "Интеграция" Glibc и повторите проверку. Если она не удалась, видимо, вы забыли наложить вышеупомянутый патч GCC Specs.