LFS_Book/chapter05/toolchaintechnotes.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>

<sect1 id="ch-tools-toolchaintechnotes">
  <?dbhtml filename="toolchaintechnotes.html"?>

  <title>Технические примечания относительно временного набора инструментов</title>

  <para>В этом разделе объясняются детали по всему процессу сборки. Не обязательно сразу понимать все что здесь написано. Большая часть информации станет понятной в процессе сборки. К этому разделу можно обратиться в любое время.</para>

  <para>Главной задачей главы <xref linkend="chapter-temporary-tools"/> является создание временной области которая содержит требуемый набор инструментов, который может быть изолирован от хост-системы. Использование команды <command>chroot</command> в оставшихся главах обеспечит чистое окружение и беспроблемную сборку конечной системы LFS. Такой процесс был выбран чтобы минимизировать риски для новых читателей и одновременно как образовательная цель.</para>

  <note>
    <para>Перед тем как приступить, необходимо знать название платформы хост-системы, часто называемой целевой "триплет". Простой способ это определить - выполнить команду <command>config.guess</command> которая поставляется с исходными кодами многих пакетов. Распакуйте пакет Binutils и выполните команду <userinput>./config.guess</userinput> и запишите вывод. Например, для 32 битного процессора intel вывод будет <emphasis>i686-pc-linux-gnu</emphasis>. Для 64 битного - <emphasis>x86_64-pc-linux-gnu</emphasis>.</para>

    <para>Также, необходим знать название динамического компоновщика, часто называемого динамический загрузчик (не путать со стандартным компоновщиком <command>ld</command>, поставляемый в пакете Binutils). Динамический компоновщик поставляется в пакете Glibc. Он находит и загружает общие библиотеки необходимые для выполнения и запуска программ, после чего запускает программу. Название динамического компоновщика на 32-битной машине с процессором intel будет <filename
    class="libraryfile">ld-linux.so.2</filename> (<filename
    class="libraryfile">ld-linux-x86-64.so.2</filename> для 64-битных систем). Надежный способ узнать название динамического компоновщика на хост-системе - проверить произвольный бинарный файл хост-системы выполнив команду <userinput>readelf -l
    &lt;название бинарного файла&gt; | grep interpreter</userinput> и проверить вывод. Официальная ссылка, охватывающая все платформы, находится в файле <filename>shlib-versions</filename> в корне каталога с исходными кодом пакета Glibc.</para>
  </note>

  <para>Ключевые технические указания как в <xref
  linkend="chapter-temporary-tools"/> работает метод сборки:</para>

  <itemizedlist>
    <listitem>
      <para>Выполнив настройку названия платформы хост-системы, изменив поле &quot;vendor&quot;
      целевого триплета с помощью переменной окружения <envar>LFS_TGT</envar>, чтобы выполнить первую сборку пакетов Binutils и GCC с совместимым кросс-компоновщиком и кросс-компилятором. Вместо того, чтобы создать файлы для другой архитектуры, кросс-компоновщик и кросс-компилятор создадут файлы совместимые с текущим аппаратным обеспечением.</para>
    </listitem>
    <listitem>
      <para>Временные библиотеки будут скомпилированы кросс-компилятором, потому что он не зависит от хост-системы . Такой метод исключает потенциальное загрязнение целевой системы, уменьшая вероятность того, что будут включены какие либо заголовочные файлы и библиотеки хост-системы в временный набор инструментов.  Кросс компиляция также позволяет выполнять сборку как 32-битных, так и 64-битных библиотек на 64-битном совместимом аппаратном обеспечении.</para>
    </listitem>
    <listitem>
    <para>Аккуратная манипуляция с исходными кодами пакета GCC будет указывать компилятору какой целевой динамический загрузчик необходимо использовать.</para>
    </listitem>
  </itemizedlist>

  <para>Пакет Binutils устанавливается первым, потому что команда <command>configure</command> запускает GCC и Glibc и выполняет различные функциональные тесты ассемблера и компоновщика для определения какие функции программного обеспечения включить или выключить. Некорректно настроенный GCC или Glibc могут привести к неработоспособности всего временного набора инструментов, и такая проблема может проявиться только в конце сборки дистрибутива. Сбои при выполнении тестов могут сигнализировать о наличии таких ошибок.</para>

  <para>Пакет Binutils выполняет установку нового ассемблера и компоновщика в два каталога:
<filename class="directory">/tools/bin</filename> и <filename class="directory">/tools/$LFS_TGT/bin</filename>. Инструменты в одном каталоге жестко связаны. Важной особенностью компоновщика является порядок поиска библиотек. Детальную информацию можно получить используя команду <command>ld</command> с аргументом <userinput>ld --verbose | grep SEARCH</userinput>. Например команда <userinput>ld --verbose | grep SEARCH</userinput> покажет текущие пути поиска и их порядок. Она показывает, какие файлы связаны <command>ld</command> при компиляции проверочной программы и указание аргумента <parameter>--verbose</parameter> компоновщику. Например команда <userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput> покажет что все файлы были успешно открыты в процессе линковки.</para>

  <para>Следующий пакет который будет установлен - GCC. Пример вывода в процессе выполнения команды <command>configure</command> будет:</para>

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

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

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

  <para>Далее будут установлены изолированные заголовочные файлы Linux API (Linux API headers). Это позволит библиотеке C (Glibc) взаимодействовать с функциями, которые предоставляет ядро Linux.</para>

  <para>Следующий пакет который будет установлен - Glibc. Необходимые компоненты для сборки Glibc - это компилятор, инструменты для работы с бинарными файлами, и заголовочные файлы ядра Linux (Linux API headers). Проблем с компилятором, как правило, не должно быть. Поскольку Glibc будет всегда использовать компилятор ссылающийся на аргумент <parameter>--host</parameter> который будет указан программе <command>configure</command>; например, в нашем случае, компилятором будет <command>i686-lfs-linux-gnu-gcc</command>.С инструментами для работы с бинарными файлами, и заголовочными файлы ядра Linux (Linux API headers) все будет немного сложнее. Поэтому не рискуйте и используйте  доступные опции конфигурации чтобы быть абсолютно уверенным в корректности. После запуска программы <command>configure</command> проверьте содержимое файла <filename>config.make</filename> в каталоге <filename class="directory">glibc-build</filename>. Убедитесь, что используется <parameter>CC="i686-lfs-gnu-gcc"</parameter> для контроля, каким инструментом для работы с бинарными файлами и используются ли аргументы   <parameter>-nostdinc</parameter> и <parameter>-isystem</parameter> для контроля какие пути поиска будет использовать компилятор. Эти пункты подчеркивают важный аспект пакета Glibc&mdash;он очень самодостаточен с точки зрения его механизма сборки и
   обычно не полагается на значения по умолчанию для временного набора инструментов.</para>

  <para>Во время второго прохода сборки пакета Binutils мы можем использовать аргумент <parameter>--with-lib-path</parameter> чтобы сконфигурировать пути поиска для библиотеки <command>ld</command>.</para>

  <para>Для второго прохода сборки GCC, понадобится модификация исходных кодов этого пакета чтобы сообщить GCC использовать новый, созданный ранее динамический компоновщик. Несоблюдение этого требования приведет к тому, что программы будут использовать динамический компоновщик хост системы, который находится в каталоге <filename class="directory">/lib</filename>, что противоречит задачи изоляции временного набора инструментов. Начиная с этого момента ядро временного набора инструментов полностью самодостаточна и независима. Остальная часть пакетов в главе <xref linkend="chapter-temporary-tools"/> будет скомпилирована с новым пакетом Glibc в каталоге <filename
  class="directory">/tools</filename>..</para>

  <para>При входе в среду chroot в главе <xref
  linkend="chapter-building-system"/>, первый основной пакет, который будет скомпилирован - это пакет Glibc, в силу упомянутых выше аспектов самодостаточности. Как только Glibc будет установлен в каталог <filename class="directory">/usr</filename> мы выполним переключение с настроек по умолчанию временного набора инструментов и приступим к сборке остальной части.</para>

</sect1>