Перенастройка инструментального набора

Теперь, когда установлены финальные библиотеки C, пришло время снова настроить набор инструментальных средств. Набор инструментальных средств будет скорректирован таким образом, чтобы он компоновал любые вновь компилируемые программы с этими новыми библиотеками. Эта процедура аналогична процедуре, использованной на фазе "настройки" в начале главы 5, но она будет обратной. В главе 5 была выполнена перенастройка с директориев /{,usr/}lib, имеющихся в хост системе, на новый директорий /tools/lib. Теперь, перенастройка будет выполняться с того же самого директория /tools/lib на директории /{,usr/}libсистемы LFS.

Сначала сделаем резервную копию компоновщика, находящегося в директории /tools, и заменим его компоновщиком, который был создан в главе 5. Мы также создадим ссылку на его эквивалент, находящийся в директории /tools/$(gcc -dumpmachine)/bin:

mv -v /tools/bin/{ld,ld-old}mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}mv -v /tools/bin/{ld-new,ld}ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld

Затем изменим файл спецификаций GCC так, чтобы он указывал на новый динамический компоновщик. Простое удаление всех вхождений "/tools" должно дать нам правильный путь к динамическому компоновщику. Также настройте файл спецификаций так, чтобы компилятору GCC было известно, где найти правильные заголовки и стартовые файлы библиотеки Glibc. Эту задачу можно решить с помощью команды sed:

gcc -dumpspecs | sed -e 's@/tools@@g' \ -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \ -e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' > \ `dirname $(gcc --print-libgcc-file-name)`/specs

Было бы хорошо визуально просмотреть файл спецификации с тем, чтобы проверить, какие из предполагаемых изменений были в действительности сделаны.

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

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

[Requesting program interpreter: /lib/ld-linux.so.2]

Заметим, что в качестве префикса динамического компоновщика теперь будет /lib.

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

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

Если все работает правильно, то ошибок быть не должно и окончание выходного потока должно иметь следующий вид:

/usr/lib/crt1.o succeeded/usr/lib/crti.o succeeded/usr/lib/crtn.o succeeded

Проверьте, что компилятор находит правильные файлы заголовков:

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

Эта команда в случае успешного завершения должна выдать следующее:

#include <...> search starts here: /usr/include

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

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

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

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

Затем проверьте, чтобы мы использовали правильную библиотеку 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

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

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

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