На главную -> MyLDP -> Электронные книги по ОС Linux

---

Linux From Scratch (version 6.8)
Назад	Глава 5. Создание временной версии системы	Вперед

---

5.2. Технические замечания об инструментальном наборе

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

Основная задача главы 5 состоит в создании специального раздела, где будет размещен известный нам временный набор инструментальных средств, изолированный от хост системы. С помощью команды chroot можно будет переключаться в этот раздел и выполнять в этом разделе все инструкции, описываемые в оставшихся главах. В результате будет собрана свободная от каких-либо проблем чистая целевая система. Процесс сборки был разработан таким образом, чтобы он, с одной стороны, минимизировал риски для новых читателей, а с другой, быть максимально ценен с образовательной точки зрения.

Важно Прежде. чем продолжить, выясните название рабочей платформы. Простым способом определить название целевой платформы является запуск скрипта config.guess, который поставляется с исходными кодами многих пакетов. Распакуйте исходные коды пакета Binutils, запустите скрипт ./config.guess и посмотрите на выданный результат. Например, для современных 32-разрядных процессоров Intel результатом, вероятно, будет i686-pc-linux-gnu. Также выясните название динамического компоновщика, используемого на существующей платформе, который часто о называется динамическим загрузчиком (не спутайте со стандартным компоновщиком ld, который является частью пакета Binutils). Динамический компоновщик, имеющийся в пакете Glibc, находит и загружает общедоступные библиотеки, необходимые для работы программы, подготавливает программу для запуска, а затем запускает ее. Название динамического компоновщика для 32-битных машин с процессором Intel: ld-linux.so.2. Безошибочный способ определить название динамического компоновщика — это проверить на хост системе любой двоичный файл, запустив для этого команду readelf -l <имя двоичного модуля> | grep interpreter и посмотрев результат ее работы. Достаточно внушительный список всех платформ есть в файле shlib-versions, который находится в корне дерева исходных кодов Glibc.

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

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

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

Следующим устанавливаемым пакетом будет пакет GCC. Пример того, что можно увидеть во время запуска скрипта configure:

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

Это важно по причинам, указанным выше. Здесь также продемонстрировано, что конфигурационный скрипт GCC для того, чтобы найти директории, которые используются инструментальными средства, не обращается к переменной PATH. Однако, во время работы самого компилятора GCC не обязательно для поиска будут использоваться те же самые пути. Чтобы узнать, какой стандартный компоновщик будет использован вместе с gcc, запустите команду: gcc -print-prog-name=ld.

Подробную информацию от компилятора gcc можно получить, передав ему параметр командной строки -v и откомпилировав специальную фиктивную программу dummy.c. Например, с помощью команды gcc -v dummy.c можно получить подробную информацию о препроцессорной обработке, компиляции и сборки, в том числе узнать, какие пути и в каком порядке использует компилятор gcc.

Следующим будет установлен пакет Glibc. Наиболее важными факторами при сборке пакета Glibc будут компилятор, набор инструментальных средств в двоичном коде и заголовки ядра. Проблем с компилятором, как правило, не возникает, поскольку для Glibc всегда будет использоваться компилятор, указанный в параметре --host, который будет передан в конфигурационный скрипт пакета, например, в нашем случае, i686-lfs-linux-gnu-gcc. С набором инструментальных средств в двоичном коде и с заголовками ядра может быть немного сложнее. Так что, не рискуйте и используйте имеющиеся конфигурационные настройки и принудительно задайте правильные варианты. После запуска скрипта configure смотрите в файле config.make, расположенном в директории glibc-build все важное, относящееся к сборке. Обратите внимание, используется ли флаг CC="i686-lfs-gnu-gcc", указывающий, какой будет использоваться набор инструментальных средств, и используются ли флаги -nostdinc и -isystem, указывающие какие пути поиска будет использовать компилятор. Эти факторы наиболее важны для сборки пакета Glibc; что касается сборки пакетов, пакет Glibc вполне самодостаточен и, обычно, не пользуется набором инструментальных средств, используемым по умолчанию.

После того, как пакет Glibc будет установлен, измените файл спецификаций gcc так, чтобы он указывал на новый динамический компоновщик, расположенный в /tools/lib. Этот последний шаг очень важен, поскольку он обеспечивает, что поиск и компоновка будут выполняться только с использованием префикса /tools. Путь к динамическому компоновщику будет жестко встроен в каждый исполняемый файл формата ELF. В этом можно удостовериться, запустив для этого следующую команду: readelf -l <имя двоичного модуля> | grep interpreter. Внесение изменений в файл спецификаций gcc обеспечит, что все программы, компилируемые с этого момента и до конца данной главы, будут пользоваться новым динамическим компоновщиком, находящимся в /tools/lib.

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

При втором проходе сборки пакета Binutils, мы можем использовать конфигурационный переключатель --with-lib-path для того, чтобы указать пути поиска библиотек ld. С этого момента основной частью набор инструментальных средств можно будет пользоваться автономно и он будет самодостаточным. В остальной части главы 5 все пакеты будут собираться с использованием новой библиотеки Glibc.

Когда в главе 6 вы с помощью команды chroot войдете в специально подготовленную среду, первым крупным пакетом, который должен быть установлен, является пакет Glibc из-за его самодостаточности, о которой было указано выше. Как только пакет Glibc будет установлен в директории /usr, мы сразу изменим набор инструментальных средств, используемых по умолчанию, а затем перейдем к сборке оставшейся части целевой системы LFS.

---

Предыдущий раздел:	Оглавление	Следующий раздел:
Введение		Общие инструкции по компиляции

---

---