Переустановка средств

Теперь, когда мы установили новую библиотку C, пришло время переустановить наши средства. Это надо для того, чтобы вновь скомпилированые программы использовали именно новую библиотеку  C. Если говорить проще, то то, что мы сейчас сделаем, это реверсия того, что мы делали на этапе "интеграции" в прошлой главе.

Первым делом мы отрегулируем компоновщик. Для этого мы вернемся к директориям с исходниками и сборкой из второго шага установки Binutils. Установим отрегулированый компоновщик запуском следующей команды из директориии binutils-build:

make -C ld INSTALL=/tools/bin/install install

Замечание: Если вы пропустили предупреждение о нежелательности удаления директорий с исходниками и сборкой Binutils из второго шага их установки в Главе 5 или по другим причинам удалили их или у вас нет доступа к ним, не беспокойтесь, не все потеряно. Просто проигнорируйте вышеприведенную команду. В результате следующий пакет, Binutils, будет скомпонован с использованием библиотек Glibc из /tools вместо /usr. Это не идеально, но наше тестирование показывает что в обоих случаях бинарники Binutils будут идентичными.

С этого момента все компилируемые программы будут собираться только с использованием библиотек из /usr/lib и /lib. Параметр INSTALL=/tools/bin/install необходим потому, что Makefile созданый на втором шаге содержит ссылки на /usr/bin/install, который пока не установлен. Некоторые дистрибутивы содержат ссылку ginstall которая имеет первенство в Makefile и это может создать здесь проблему. Вышеуказанная команда также решает и эту проблему.

Теперь вы можете удалить обе директории Binutils.

Теперь нам необходимо исправить точки в spec файлах GCC, которые указывают на динамический компоновщик, так, чтобы они указывали на новый компоновщик. Савым простым будет следующее:

SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
sed -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
$SPECFILE > newspecfile &&
mv -f newspecfile $SPECFILE &&
unset SPECFILE

Желательно просто скопировать и вставить эту команду. После этого также неплохо бы было проверить spec файлы, чтобы убедиться в сделаных изменениях.

Важно: Если вы работаете на платформах, на которых имя динамического компоновщика отличается от ld-linux.so.2, вы должны заменить ld-linux.so.2 на имя компоновщика для вашей платформы в вишеуказанной команде. Вернитесь к части Технрические моменты в Главе 5 если у вас возникли вопросы.

 

Внимание

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

echo 'main(){}' > dummy.c
gcc dummy.c
readelf -l a.out | grep ': /lib'

Если все в порядке, то не будет ошибок и на выводе вы увидите:

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

Если эта надпись вообще не появилась или появилась другая, то чтото сильно не так. Вам надо исследовать и повторить все пройденые шаги, чтобы найти в чем проблема и устранить ее. Точки для возврата после этого места уже не будет. Как правило, что-то не так бывает с вышеописаной правкой specs-фала. Убедитесь, что /lib содержит префикс вашего динамического компоновщика. Само собой, если вы работаете на платформе с названием динамического компоновщика, отличным от ld-linux.so.2, вывод будет несколько иным.

Если все прошло нормально, удалим тестовые файлы:

rm dummy.c a.out

 



Наш баннер
Вы можете установить наш баннер на своем сайте или блоге, скопировав этот код:
RSS новости