Установка 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++

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

  • --enable-threads=posix: Это подключит расширение C++ для мультилинейного кода.

  • --enable-__cxa_atexit: Эта опция разрешит использование __cxa_atexit, которое предпочтительнее использования atexit, для регистрации деструкторов C++ для локальных и глобальных объектов для обеспечения полного соответствия стандартам ссылок на деструкторы. Он также повлияет на C++ ABI и некоторые другие результаты в библиотеках C++ и программах C++, которые взаимодействуют с другими дистрибутивами Linux.

  • --enable-clocale=gnu: Эта опция позволяет убедиться в корректном выборе модели локали для библиотек C++ во всех обстоятельствах. Если скрипт конфигурации найдет установленную локаль de_DE, он выберет корректную модель gnu. Тем не менее, люди, которые не установили локаль de_DE рискуют собрать ABI-несовместимую библиотеку C++ из-за неверной модели локали в общем случае.

  • --enable-languages=c,c++: Эта опция позволяет убедиться, что будут собраны компиляторы 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.



Наш баннер
Вы можете установить наш баннер на своем сайте или блоге, скопировав этот код:
RSS новости