Примените команду подстановки sed, с помощью которой будет отменена установка библиотеки libiberty.a. Вместо нее будет использована версия библиотеки libiberty.a из пакета Binutils:
sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in
Как и в разделе 5.10 "Пакет GCC-4.5.2 — Второй проход" применяется следующая команда sed, которая при сборке заставит использовать флаг компилятора -fomit-frame-pointer с тем, чтобы обеспечить надлежащую сборку компилятора:
case `uname -m` in i?86) sed -i 's/^T_CFLAGS =$/& -fomit-frame-pointer/' \ gcc/Makefile.in ;;esac
Как известно, иногда ошибочно делается попытка с помощью скрипта fixincludes "исправить" системные заголовки, которые были установлены к настоящему моменту. Поскольку известно, что заголовки, установленные к настоящему моменту, не требуют исправлений, введите следующую команду, чтобы предотвратить запуск скрипта fixincludes:
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
В документации GCC рекомендуется собирать GCC в отдельном директории для сборки, а не в директории с исходными кодами:
Обратите внимание, что для других языков, есть некоторые дополнительные настройки, которые здесь отсутствуют. Инструкции о том, как собрать все языки, поддерживаемые в GCC, смотрите в книге BLFS.
Пояснение нового конфигурационного параметра:
--with-system-zlib
Этот переключатель укажет GCC использовать для компоновки копию библиотеки Zlib, установленную в системе, а не свою собственную внутреннюю копию.
Откомпилируйте пакет:
make
Важно
В этом разделе выполнение набора тестов для Glibc считается важным. Не пропускайте его ни при каких обстоятельствах.
Известно, что для одного из наборов тестов из тестового набора пакета GCC происходит переполнение стека, так что перед запуском тестов увеличьте размер стека:
ulimit -s 16384
Проверьте результаты, но не останавливайтесь в случае обнаружения ошибок
make -k check
Чтобы получить общий итог результатов выполнения тестового набора, запустите команду:
../gcc-4.5.2/contrib/test_summary
Для получения только общего итога перенаправьте выходной поток через конвейер grep -A7 Summ.
Полученные результаты можно сравнить с теми, которые опубликованы на http://www.linuxfromscratch.org/lfs/build-logs/6.8/ и на http://gcc.gnu.org/ml/gcc-testresults/.
Не всегда удается избежать некоторых неожиданных сбоев. Разработчикам GCC, как правило, известно об этих проблемах, но к настоящему моменту они не решены. В частности, известно, что тесты libmudflapособенно проблематичны из-за ошибки в GCC (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003). Если результаты теста не сильно отличаются от тех, что приведены по указанному выше URL, сборку можно с уверенностью продолжить.
Установите пакет:
make install
Для некоторых пакетов ожидается, что в директории /lib установлен препроцессор С. Чтобы поддержать использование этих пакетов, создайте следующую символическую ссылку:
ln -sv ../usr/bin/cpp /lib
Во многих пакетах для вызова компилятора С используется команда cc. Чтобы поддержать использование этих пакетов, создайте символическую ссылку:
ln -sv gcc /usr/bin/cc
Теперь, когда наш окончательный набор инструментальных средств установлен там, где надо, снова обеспечьте, чтобы компиляция и компоновка работали так, как ожидалось. Мы делаем это с помощью точно таких же чистовых проверок, которые мы делали ранее в этой главе:
Если все работает правильно, то ошибок быть не должно, а последняя выданная строка будет иметь следующий вид (с учетом разницы именования динамического компоновщика, зависящего от платформы):
[Requesting program interpreter: /lib/ld-linux.so.2]
Теперь удостоверьтесь, что мы сделали настройки, позволяющие использовать правильные стартовые файлы:
В зависимости от архитектуры вашей машины, приведенные выше данные могут немного отличаться, разница обычно состоит в имени директория, идущего после /usr/lib/gcc. Если у вас 64-разрядная машина, вы вы в конце строки можете увидеть директорий с именем lib64. Здесь важно увидеть, что компилятор gcc нашел в директории /usr/lib все три файла crt*.o.
Проверьте, что компилятор находит правильные заголовочные файлы:
grep -B4 '^ /usr/include' dummy.log
Эта команда в случае успешного завершения должна выдать следующее:
Снова обратите внимание на то, что в зависимости от вашей архитектуры, имена директориев могут отличаться.
Замечание
Поскольку версия 4.3.0 компилятора GCC теперь всегда устанавливает файл limits.h в приватный директорий limits.h, необходимо, чтобы этот директорий уже был.
Затем проверьте, что новый компоновщик использует правильные пути поиска:
Если все работает правильно, то ошибок быть не должно, и последние выдаваемые строки будут иметь следующий вид (с учетом разницы именования динамического компоновщика, зависящего от платформы):
Затем проверьте, что мы используем правильную библиотеку libc:
grep "/lib.*/libc.so.6 " dummy.log
Если все работает правильно, то ошибок быть не должно, а последняя выданная строка будет иметь следующий вид (с учетом того, что для хостов с 64-разрядной архитектурой будет использована библиотека lib64):
attempt to open /lib/libc.so.6 succeeded
Наконец, убедитесь, что компилятор GCC использует правильный динамический компоновщик:
grep found dummy.log
Если все работает правильно, то ошибок быть не должно, а последняя выданная строка будет иметь следующий вид (с учетом разницы именования динамического компоновщика, зависящего от платформы, и учетом того, что для хостов с 64-разрядной архитектурой будет использована библиотека lib64):
found ld-linux.so.2 at /lib/ld-linux.so.2
Если вывод не такой, как показано выше, или вообще ничего не выдано, то где-то серьезная ошибка. Изучите и повторите все шаги с тем, чтобы выяснить, в чем проблема и устраните ее. Возможно, что-то было сделано неверно в процессе правки файла спецификаций. Проблему нужно решить раньше, чем двигаться дальше.
После того, как все будет проверено, удалите тестовые файлы:
