Версии компилятора GCC, более поздние, чем 4.3, будут трактоваться процессом сборки, как если бы местоположение компилятора было изменено, и там, куда указывает параметр --prefix, поиск стартовых файлов происходить не будет. Поскольку компилятор никуда не перемещался, а стартовые файлы, находящиеся в директории /tools, важны для сборки работающего компилятора, скомпонованного с библиотеками, расположенными в /tools, примените следующий патч, который частично восстановит старое поведение GCC:
patch -Np1 -i ../gcc-4.5.2-startfiles_fix-1.patch
При нормальных условиях скрипт fixincludes из GCC запускается для того, чтобы исправить возможно испорченные заголовочные файлы. Поскольку к этом моменту пакеты GCC-4.5.2 и Glibc-2,13 уже установлены и известно, что соответствующие заголовочные файлы не требуют правки, скрипт fixincludes не нужен. На самом деле, запуск этого скрипта может в действительности загрязнить среду сборки из-за того, что установит в личном директории include компилятора GCC скорректированные заголовки, взятые из хост системы. Запуск скрипта fixincludes можно подавить с помощью следующих команд:
Для машин c архитектурой x86, при сборке GCC методом "раскрутки" (bootstrap) используется флаг компилятора -fomit-frame-pointer. Если сборка осуществляется без "раскрутки", то, по умолчанию, этот флаг не указывается, но нужно создать точно такой же компилятор, как тот, что собирается методом "раскрутки". Используйте следующую команду sed, которая принудительно заставит выполнять сборку с этим флага:
Следующая команда изменит место, где по умолчанию должен находиться динамический компоновщик GCC; будет использоваться компоновщик, который находится в /tools. Команда также удалит /usr/include из путей поиска include в GCC. С помощью этой команды, а не с помощью настройки файла спецификаций будет после установки гарантировано, что во время фактической сборки GCC будет использован новый динамический компоновщик. То есть, все файлы, созданные во время сборки, будут ссылаться на новую библиотеку Glibc. Наберите:
Поскольку приведенный выше текст сложен, давайте разберем его по частям. Сначала мы находим в директории gcc/config все файлы с именами linux.h, linux64.h или sysv4.h. Для каждого найденного файла, мы копируем его в файл с таким же названием, но с расширением ".orig" (оригинальный). Затем первое выражение sed добавит префикс "/tools" к каждому найденному вхождению "/lib/ld", "/lib64/ld" или "/lib32/ld", второе выражение заменяет жестко запрограммированные ссылки "/usr". Затем мы добавляем наши инструкции define, которые изменят пути поиска include, а в конце файла добавляется префикс стартового файла, используемого по умолчанию. Наконец, мы используем команду touch чтобы обновить временные метки скопированных файлов. Если ее использовать вместе с командной cp -u, то в случае, если команда была непреднамеренно запущена дважды, будут предотвращены неожиданные изменения исходных файлов.
На машинах с архитектурой x86_64, отключение спецификации multilib для GCC гарантирует, что попыток компоновки с библиотеками, находящимися на хост системы, не будет:
case $(uname -m) in x86_64) for file in $(find gcc/config -name t-linux64) ; do \ cp -v $file{,.orig} sed '/MULTILIB_OSDIRNAMES/d' $file.orig > $file done ;;esac
Как и при первой сборке GCC, потребуются пакеты GMP, MPFR и MPC. Распакуйте архивы и переместите их в директории с соответствующими именами:
Перед тем, как начать сборку GCC, не забудьте сбросить все переменные среды окружения, которые изменены оптимизационными флагами, используемыми по умолчанию.
Этот параметр гарантирует, чтобы при любых обстоятельствах для библиотек C++ будет выбрана правильная модель локали. Если скрипт configure найдет установленную локаль de_DE, он выберет правильную модель локали gnu. Но, если локаль de_DE не установлена, то поскольку может быть выбрана неправильная базовая модель локали, есть риск собрать библиотеки C++, которые будут несовместимы с интерфейсом Application Binary Interface (ABI).
--enable-threads=posix
Этот параметр обеспечивает обработку в многопоточном коде исключительных состояний C++.
--enable-__cxa_atexit
Этот параметр позволяет при регистрации деструкторов C++ для локальных статических и глобальных объектов использовать __cxa_atexit, а не atexit. Этот параметр очень важен для того, чтобы обработка деструкторов полностью соответствовала стандартам. Параметр также влияет на C++ ABI, и собираемые в результате общие библиотеки C++ и программы C++ будут совместимы с другими дистрибутивами Linux.
--enable-languages=c,c++
Этот параметр гарантирует, что будут собраны оба компилятора C и C++.
Для нативной сборки GCC, сборка по умолчанию осуществляется методом "раскрутки" (bootstrap). Это не только компиляция GCC, а многократная компиляция. Программы, откомпилированные на первом проходе, будут во второй раз использоваться для компиляции сами себя, а затем, снова, третий раз. Вторая и третья итерации выполняются с тем, чтобы убедиться, что компилятор может безупречно воспроизводить сам себя. Из этого также следует, что компилятор откомпилирован правильно. Но метод, используемый в системе LFS, должен позволять собирать надежный компилятор и не обращаться каждый раз к методу "раскрутки".
Откомпилируйте пакет:
make
Установите пакет:
make install
В качестве последнего штриха создайте символическую ссылку. Во многих программах и скриптах вместо gcc запускается cc с тем, чтобы программы имели более общий вид и, следовательно, могли бы использоваться на всех видах систем UNIX, где компилятор GNU C не всегда установлен. Запуск cc позволяет системному администратору не задумываться о том, какой компилятор устанавливать:
ln -vs gcc /tools/bin/cc
Внимание
В этот момент следует остановиться и убедиться, что основные функции (компиляция и компоновка) нового набора инструментальных средств работают так, как ожидалось. Что сделать чистовую проверку, выполните следующие команды:
Если все работает правильно, то ошибок быть не должно, а вид последней выданной строки должен быть следующим:
[Requesting program interpreter: /tools/lib/ld-linux.so.2]
Заметим, что в качестве префикса динамического компоновщика может указываться /tools/lib, либо /tools/lib64 для 64-битных машин.
Если вывод не такой, как показано выше, или вообще ничего не выдано, то где-то ошибка. Изучите и повторите все шаги с тем, чтобы выяснить, в чем проблема и устраните ее. Проблему нужно решить раньше, чем двигаться дальше. Во-первых, снова выполните чистовую проверку, используя gcc вместо cc. Если это сработает, то значит, что символическая ссылка /tools/bin/cc отсутствует. Установите ссылку так, как это указано выше. Затем убедитесь, что путь PATH правильный. В этом можно убедиться, запустив команду echo $PATH и проверив, что в начале списка присутствует /tools/bin. Если путь PATH не такой, то это может означать, что вы вошли в систему не как пользователь lfs или в разделе 4.4 "Настройка среды окружения" что-то пошло не так.
После того, как все будет проверено, удалите тестовые файлы:
rm -v dummy.c a.out
Подробности об этом пакете приведены в разделе 6.16.2 "Описание пакета GCC".
