Теперь, когда мы установили новую библиотку C, пришло время переустановить наши средства. Это надо для того, чтобы вновь скомпилированные программы использовали именно новую библиотеку C. То, что мы сейчас сделаем, это реверс того, что мы делали на этапе “интеграции” в начале Главы 5. В Главе 5 была проведена цепь из основных директорий /{,usr/}lib в новую директорию /tools/lib. Теперь цепь будет проведена из этой самой директории /tools/libв директорию LFS /{,usr/}lib.
Первым делом мы отрегулируем компоновщик. Для этого мы вернемся к директориям с исходниками и сборкой из второго шага установки Binutils. Установим отрегулированый компоновщик запуском следующей команды из директориии binutils-build:
make -C ld INSTALL=/tools/bin/install install
Если вы пропустили предупреждение о нежелательности удаления директорий с исходниками и сборкой Binutils на втором шаге их установки в Главе 5 или по другим причинам удалили их или у вас нет доступа к ним, не беспокойтесь, не все потеряно. Просто проигнорируйте вышеприведенную команду. В результате следующий пакет Binutils будет скомпонован с использованием библиотек Glibc из /tools вместо /{,usr/}lib. Это не идеально, но наше тестирование показывает что в обоих случаях бинарники Binutils будут идентичными.
С этого момента все компилируемые программы будут собираться только с использованием библиотек из /usr/lib и /lib. Параметр INSTALL=/tools/bin/install необходим потому, что файл Makefile, созданый на втором шаге, содержит ссылки на /usr/bin/install, который пока не установлен. Некоторые дистрибутивы содержат ссылку ginstall которая имеет первенство в файле Makefile и это может создать здесь проблему. Вышеуказанная команда также решает и эту проблему.
Теперь вы можете удалить обе директории Binutils.
Теперь нам необходимо исправить точки в spec файлах GCC, которые указывают на динамический компоновщик так, чтобы они указывали на новый компоновщик. Выполним следующее:
sed -i 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
`gcc --print-file specs`
После этого также неплохо было бы проверить spec файлы, чтобы убедиться в сделаных изменениях.
Если вы работаете на платформе, на которой имя динамического компоновщика отличается от ld-linux.so.2, замените “ld-linux.so.2” на имя компоновщика для вашей платформы в вышеуказанной команде. Вернитесь к Разделу 5.3, “Технические моменты”, если необходимо.
На этом месте необходимо остановиться и убедиться, что основные функции (компиляция и компоновка) новых средств работают корректно. Для этого есть простой тест:
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /lib'
Если все в порядке, то не будет ошибок и на выводе вы увидите:
[Requesting program interpreter: /lib/ld-linux.so.2]
Заметьте, что /lib теперь является префиксом нашего компоновщика.
Если эта надпись вообще не появилась или появилась другая, то что-то сильно не так. Вам надо исследовать и повторить все пройденые шаги, чтобы найти в чем проблема и устранить ее. Точки для возврата после этого места уже не будет. Как правило, что-то не так бывает с вышеописаной правкой specs-фала. Любые проблемы необходимо устранить перед продолжением процесса.
Если все прошло нормально, удалим тестовые файлы:
rm dummy.c a.out