8.26. GCC-12.2.0

8.26.1. Установка пакета GCC

При сборке на x86_64 измените имя каталога по умолчанию для 64-битных библиотек на «lib»:

case $(uname -m) in
  x86_64)
    sed -e '/m64=/s/lib64/lib/' \
        -i.orig gcc/config/i386/t-linux64
  ;;
esac

Документация GCC рекомендует собирать GCC в отдельном каталоге:

mkdir -v build
cd       build

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

../configure --prefix=/usr            \
             LD=ld                    \
             --enable-languages=c,c++ \
             --enable-default-pie     \
             --enable-default-ssp     \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib

GCC поддерживает семь различных языков программирования, но предварительные условия для большинства из них еще не выполнены. См. страницу BLFS Book GCC для получения инструкций о том, как собрать все языки, поддерживаемые GCC

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

make

Известно, что один набор тестов GCC переполняет стек по умолчанию, поэтому увеличьте размер стека перед запуском тестов:

ulimit -s 32768

Выполните тестирование под непривилегированным пользователем, но не останавливайтесь на ошибках:

chown -Rv tester .
su tester -c "PATH=$PATH make -k check"

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

../contrib/test_summary

Чтобы отфильтровать только итоговую сводку, передайте вывод через pipe grep -A7 Summ.

Результаты можно сравнить с результатами, размещенными на https://mirror.linuxfromscratch.ru/lfs/build-logs/11.3/ и https://gcc.gnu.org/ml/gcc-testresults/.

Известно, что одиннадцать тестов в наборе тестов i386 для компилятора gcc завершаются неудачно. Это связано с тем, что в тестовых файлах не учитывается параметр --enable-default-pie.

Четыре теста, относящиеся к PR100400, сообщают как XPASS, так и FAIL при проверке компилятора g++. Это происходит потому что тестовый файл написан не очень хорошо.

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

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

make install

Каталог сборки GCC теперь принадлежит пользователю tester, и владелец каталога заголовочных файлов (и его содержимого) указан неверно. Измените владельца на пользователя и группу root:

chown -v -R root:root \
    /usr/lib/gcc/$(gcc -dumpmachine)/12.2.0/include{,-fixed}

Создайте символическую ссылку, требуемую FHS по "историческим" причинам.

ln -svr /usr/bin/cpp /usr/lib

Добавьте символическую ссылку совместимости, чтобы включить сборку программ с оптимизацией времени компоновки (LTO):

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/12.2.0/liblto_plugin.so \
        /usr/lib/bfd-plugins/

Теперь, когда наш окончательный набор инструментов готов, важно еще раз убедиться, что компиляция и компоновка будут работать так, как ожидалось. Мы сделаем это, выполнив проверку работоспособности:

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

Ошибок быть не должно, и вывод последней команды будет (с учетом платформо-зависимых различий в имени динамического компоновщика):

[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Теперь убедитесь, что мы настроили использование правильных стартовых файлов:

grep -E -o '/usr/lib.*/S?crt[1in].*succeeded' dummy.log

Вывод последней команды должен быть:

/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/Scrt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/crtn.o succeeded

В зависимости от архитектуры вашего компьютера вышеуказанные параметры могут незначительно отличаться. Разница будет заключаться в имени каталога после /usr/lib/gcc. Здесь важно обратить внимание на то, что gcc нашел все три файла crt*.o в каталоге /usr/lib.

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

grep -B4 '^ /usr/include' dummy.log

Эта команда должна вернуть следующий вывод:

#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include-fixed
 /usr/include

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

Затем убедитесь, что новый компоновщик использует правильные пути поиска:

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

Ссылки на пути, содержащие компоненты с '-linux-gnu', следует игнорировать, но в противном случае вывод последней команды должен быть таким:

SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

32-разрядная система может использовать несколько других каталогов. Например, вот вывод с компьютера i686:

SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32")
SEARCH_DIR("/usr/local/lib32")
SEARCH_DIR("/lib32")
SEARCH_DIR("/usr/lib32")
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

Затем убедитесь, что мы используем правильную libc:

grep "/lib.*/libc.so.6 " dummy.log

Вывод последней команды должен быть:

attempt to open /usr/lib/libc.so.6 succeeded

Убедитесь, что GCC использует правильный динамический компоновщик:

grep found dummy.log

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

found ld-linux-x86-64.so.2 at /usr/lib/ld-linux-x86-64.so.2

Если вывод выглядит не так, как показано выше, или вообще не получен, значит, где-то серьезная ошибка. Изучите и повторите шаги, чтобы выяснить, в чем проблема, и исправьте ее. Любые проблемы должны быть решены, прежде чем вы продолжите процесс.

Как только все заработает правильно, удалите тестовые файлы:

rm -v dummy.c a.out dummy.log

Наконец, переместите файл:

mkdir -pv /usr/share/gdb/auto-load/usr/lib
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib