Библиотека сайта rus-linux.net
5.9. "Интеграция" средств
Теперь, когда временные библиотеки C были установлены, мы хотим, чтобы все оставшиеся в этой главе пакеты компоновались с использованием уже установленных библиотек. Чтобы обеспечить это, мы должны настроить specs файл компилятора.
Заменим компоновщик, установленный в конце первого шага сборки Binutils,
запуском следующей команды в директории binutils-build:
make -C ld install
С этого момента все пакеты быдут собраны только с использованием библиотек из
/tools/lib.
![[Note]](../images/note.png)
Замечание
Если вы пропустили предупреждение о том, что не надо было удалять директории с исходниками и сборкой Binutils из первого шага или у вас нет доступа к ним, не беспокойтесь, не все потеряно. Просто проигнорируйте вышеприведенную команду. В результате появится небольшой шанс, что программы будут скомпонованы с использованием библиотек основной системы. Это не очень хорошо, но тем не менее не является такой уж большой проблемой. Ситуация будет исправлена позже на втором шаге установки Binutils.
Теперь, когда установлен откорректированый компоновщик, вы можете удалить директории с исходниками и сборкой Binutils.
Следующим нашим действием будет исправление specs-файла GCC для задания расположения нашего компоновщика. Просто выполните следующую команду:
SPECFILE=`gcc --print-file specs` &&
sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
$SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE
Мы рекомендуем просто скопировать и вставить вышеуказанное вместо того, чтобы просто вводить. Или, при желании, вы можете просто отредактировать specs-файл вручную, заменив встречающиеся строки “/lib/ld-linux.so.2” на “/tools/lib/ld-linux.so.2”
![[Important]](../images/important.png)
Важно
Если вы работаете на платформе, где имя динамического компоновщика
отлично от ld-linux.so.2,
замените“ld-linux.so.2”
на имя динамического компоновщика вашей платформы в вышеуказанных командах.
При необходимости вернитесь к Разделу 5.3.
Есть возможность, что некоторые включаемые файлы из основной системы имеются внутри директорий для включаемых файлов GCC. Это могло произойти по причине того, что процесс “fixincludes” запускается как часть сборки GCC. Позже мы раскажем об этом подробнее в этой главе. А пока запустите следующую команду, чтобы исключить эту возможность:
rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}
![[Caution]](../images/caution.png)
Внимание
На этом месте необходимо остановиться и убедиться, что основные функции (компиляция и компоновка) новых средств работают корректно. Для этого есть простой тест:
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'
Если все в порядке, то не будет ошибок и вы увидите следующее:
[Requesting program interpreter: /tools/lib/ld-linux.so.2]
Заметим, что /tools/lib становится
префиксом динамического компоновщика.
Если эта надпись вообще не появилась или появилась другая, то что-то
сильно не так. Вам надо исследовать и повторить все пройденые шаги,
чтобы найти в чем проблема и устранить ее. Точки для возврата после
этого места уже не будет. Сначала опять проведите предыдущий тест,
используя gcc вместо
cc. Если это работает, тогда
отсутствует ссылка /tools/bin/cc.
Обратитесь к Разделу 5.5, “GCC-3.4.1 -
Шаг 1” и установите ссылку. Следующее, убедитесь в корректности
PATH. Это можно проверить запуском команды
echo $PATH и проверить, что
/tools/bin является первым в списке.
Если PATH ошибочен, это может означать, что вы
зарегистрировались не как пользователь lfs или что что-то прошло не правильно
в Разделе 4.4,
“Установка переменных окружения”. С другими опцииями
что-нибудь может пойти не так при исправлении в specs-файле выше.
В этом случае, подправьте исправление в specs-файле, будьте
осторожны при копировании и вставке команд.
Если все прошло нормально, удалим тестовые файлы:
rm dummy.c a.out