Технические моменты

Этот раздел предназначен для объяснения некоторых логических и технических моментов рационального метода сборки. Ничего страшного, если вы не поймете все, что написано здесь. Большая часть из них имеет значение при выполнении сборки конкретных пакетов. Вы можете вернуться сюда в любое время.

Основной целью Главы 5 является подготовка окружения для входа через chroot для создания полноценной системы в Главе 6. По ходу дела мы соберем, используя основную систему, самодостаточные средства. Это будет сделано для обеспечения минимального риска и максимальной независимости одновременно. Другими словами, мы соберем инструменты для сборки системы.

Некоторые технические моменты которые позволяют методам сборки из Главы 5 работать:

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

• Осторожная манипуляция путями поиска библиотек стандартным компоновщиком для того, чтобы убедиться, что программы были скомпонованы с использованием выбранных нами библиотек.

• Осторожная манипуляция specs- файлом gcc для передачи компилятору информации об используемом динамическом компоновщике.

Binutils устанавливаются первыми потому, что GCC и Glibc выполняют тестирование ассемблера и компоновщика во время запуска ./configure для определения того, какие настройки программного обеспечения выбраны или отключены. Это очень важно при перфой реализации. Неверно сконфигурированые GCC и Glibc могут испортить все сборку средств и дистрибутив будет с ошибками. Благодаря тестированию мы можем опрделить это своевременно.

Binutils устанавливают ассемблер и компоновщик в два места: /tools/bin и /tools/$TARGET_TRIPLET/bin. Точнее, средства в одной из директорий являются шесткими ссылками на другие. Очень важным для компоновщика является порядок поиска библиотек. Точную информацию о нем можно получить от ld указав параметр --verbose. К примеру: 'ld --verbose | grep SEARCH' покажет текущие пути поиска и их порядок. Вы можете увидеть, какие файлы скомпонованы с помощью ld при компиляции программы-пустышки и используя переключатель --verbose. К примеру: 'gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded' какие файлы были открыты удачно в процессе компоновки.

Следующим пакетом мы установим GCC и в процессе работы ./configure вы увидите, например:

checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld

Это важно по причинам, описаным выше. И это также показывает, что скрипт конфигурации GCC не ищет в директориях $PATH какие средства использовать. Тем не менее, текущий процесс gcc, не использует эти пути поиска. Вы можете определить, какой стандартный комполновщик gcc используется, запуском: 'gcc -print-prog-name=ld'. Детальная информация получается от gcc добавлением параметра -v при компиляции. Например: 'gcc -v dummy.c' покажет полную информацию о препроцессоре, компиляторе и ассемблере, включая пути поиска gcc и другую информацию.

Следующим устанавливаемым пакетом будет Glibc. Наиболее важными зависимостями сборки Glibc являются компилятор, средства для бинарных файлов и заголовки ядра. TКомпилятор не представляет проблемы, Glibc всегда использует gcc из директории $PATH. Бинарные средства и заголовки ядра могут привести к некоторым проблемам. Поэтому мы не рискуем и используем переключатели конфигурации для правильного выбора. После запуска ./configure вы можете проверить содержимое файла config.make в директории glibc-build для получения информации. Вы быдете использовать некотоые интересные параметры, такие как CC="gcc -B/tools/bin/" которые определяют используемые средства, а также флаги -nostdinc и -isystem для контроля за путем поиска для компилятора. Эти параметры показывают важный аспект пакета Glibc: он не обязательно полагается на средства по умолчанию.

После установки Glibc, мы создадим некоторые установки для того, чтобы убедиться что пути для поиска содержат только директории в /tools . Мы установим откорректированный ld, в котором будет жестко указан путь поиска в /tools/lib. Задем мы исправим specs-файл gcc для указания на наш новый динамический компоновщик в /tools/lib. Этот последний шаг жизненно важен для нашего процесса. Как указано выше, путь к динамическому компоновщику будет жестко вшит в каждый исполняемый файл ELF. Вы можете убедиться в этов, запустив 'readelf -l <name of binary> | grep interpreter'. Благодаря исправлению specs-файла gcc, мы убедимся, что все программы из оставшейся части Главы 5 будут использовать новый динамический комполовщик из /tools/lib.

Необходимость использования нового динамического компоновщика также является причиной, по которой мы применяем Specs патч на втором этапе сборки GCC. Опускание этого патча приведет к тому, что программы GCC будут использовать системный динамический компоновщик из директории /lib основной системы, а ето будет означать зависимость от основной системы.

В ходе второго шага сборки Binutils мы будем использовать переключатель --with-lib-path для контроля путя поиска библиотек для ld. С этого момента все наши средства будут самодостаточными. Остальные пакеты из Главы 5 будут собраны с новым Glibc из /tools.

После входа в окружение chroot в Главе 6, мы первым делео установим Glibc по вышеописаным причинам. Теперь Glibc будет установлен в /usr, и мы будем использовать средства по умолчанию для сборки остальных пакетов из Главы 6 для LFS системы.