diff options
Diffstat (limited to 'lfs-12.1-sysv/partintro/toolchaintechnotes.html')
| -rw-r--r-- | lfs-12.1-sysv/partintro/toolchaintechnotes.html | 743 |
1 files changed, 743 insertions, 0 deletions
diff --git a/lfs-12.1-sysv/partintro/toolchaintechnotes.html b/lfs-12.1-sysv/partintro/toolchaintechnotes.html new file mode 100644 index 0000000..f969bb1 --- /dev/null +++ b/lfs-12.1-sysv/partintro/toolchaintechnotes.html @@ -0,0 +1,743 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" /> + <title> + Технические примечания по сборочным инструментам + </title> + <link rel="stylesheet" type="text/css" href="../stylesheets/lfs.css" /> + <meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /> + <link rel="stylesheet" href="../stylesheets/lfs-print.css" type= + "text/css" media="print" /> + <meta name="viewport" content="width=device-width, initial-scale=1.0" /> + </head> + <body class="lfs" id="lfs-12.1"> + <div class="navheader"> + <h4> + Линукс с нуля - Версия 12.1 + </h4> + <h3> + Важный предварительный материал + </h3> + <ul> + <li class="prev"> + <a accesskey="p" href="introduction.html" title= + "Введение">Пред.</a> + <p> + Введение + </p> + </li> + <li class="next"> + <a accesskey="n" href="generalinstructions.html" title= + "Общие инструкции по компиляции">След.</a> + <p> + Общие инструкции по компиляции + </p> + </li> + <li class="up"> + <a accesskey="u" href="partintro.html" title= + "Важный предварительный материал">Наверх</a> + </li> + <li class="home"> + <a accesskey="h" href="../index.html" title= + "Линукс с нуля - Версия 12.1">Начало</a> + </li> + </ul> + </div> + <h1 class="sect1"> + <a id="ch-tools-toolchaintechnotes" name= + "ch-tools-toolchaintechnotes"></a>ii. Технические примечания по + сборочным инструментам + </h1> + <div class="sect1" lang="ru" xml:lang="ru"> + <p> + В этом разделе объясняются причины и некоторые технические детали, + лежащие в основе сборки пакетов. Не обязательно сразу понимать все, + что содержится в этом разделе. Большая часть этой информации станет + более понятной после выполнения фактической сборки. Возвращайтесь и + перечитывайте этот раздел в любое время по ходу сборки. + </p> + <p> + Основная задача <a class="xref" href="../chapter05/chapter05.html" + title="Глава 5. Сборка кросс-тулчейна">Глава 5</a> и <a class= + "xref" href="../chapter06/chapter06.html" title= + "Глава 6. Кросс-Компиляция временных инструментов">Глава 6</a> + состоит в том, чтобы создать временную область, содержащую заведомо + исправный набор инструментов, которые можно изолировать от + хост-системы. Использовании команды <span class= + "command"><strong>chroot</strong></span> в последующих главах, + обеспечит чистую и безотказную сборку целевой системы LFS. Процесс + сборки разработан таким образом, чтобы свести к минимуму риски для + новых читателей и в то же время обеспечить наибольшую образовательную + ценность. + </p> + <p> + Сборка инструментария основана на процессе <span class= + "emphasis"><em>кросс-компиляции</em></span>. Кросс-компиляция обычно + используется для сборки компилятора и его инструментов для машины, + отличной от той, которая используется для сборки. Строго говоря, это + не требуется для LFS, так как машина, на которой будет работать новая + система, та же, что и используемая для сборки. Но у кросс-компиляции + есть большое преимущество, заключающееся в том, что все, что + подвергается кросс-компиляции, не будет зависеть от окружения хоста. + </p> + <div class="sect2" lang="ru" xml:lang="ru"> + <h2 class="sect2"> + <a id="cross-compile" name="cross-compile"></a>О кросс-компиляции + </h2> + <div class="admon note"> + <img alt="[Примечание]" src="../images/note.png" /> + <h3> + Примечание + </h3> + <p> + Книга LFS не является руководством и не содержит общего + руководства по созданию кросс (или собственного) тулчейна. Не + используйте команды из книги для кросс-тулчейна, который + планируете использовать для каких-либо других целей, кроме + создания LFS, если у вас нет полного понимания, что вы делаете. + </p> + </div> + <p> + Кросс-компиляция включает в себя некоторые концепции, которые сами + по себе заслуживают отдельного раздела. Хотя этот раздел можно + пропустить при первом чтении, возвращение к нему позже будет + полезно для полного понимания процесса. + </p> + <p> + Давайте определим некоторые термины, используемые в этом контексте. + </p> + <div class="variablelist"> + <dl class="variablelist"> + <dt> + <span class="term">сборщик</span> + </dt> + <dd> + <p> + это машина, на которой мы собираем программы. Обратите + внимание, что этот компьютер упоминается как <span class= + "quote">«<span class="quote">хост</span>»</span> в других + разделах. + </p> + </dd> + <dt> + <span class="term">хост</span> + </dt> + <dd> + <p> + это машина/система, на которой будут выполняться встроенные + программы. Обратите внимание, что используемое здесь значение + слова <span class="quote">«<span class= + "quote">хост</span>»</span> отличается от того, которое + применяется в других разделах. + </p> + </dd> + <dt> + <span class="term">цель</span> + </dt> + <dd> + <p> + используется только для компиляторов. Это машина, для которой + компилятор создает код. Он может отличаться как от + <span class="quote">«<span class= + "quote">сборщика</span>»</span>, так и от <span class= + "quote">«<span class="quote">хоста</span>»</span>. + </p> + </dd> + </dl> + </div> + <p> + В качестве примера представим следующий сценарий (иногда называемый + <span class="quote">«<span class="quote">канадским + крестом</span>»</span>): у нас есть компилятор на медленной машине, + назовем ее машиной A и компилятор ccA. У нас также есть быстрая + машина (B), но без компилятора, и мы хотим создать код для другой + медленной машины (C). Чтобы собрать компилятор для машины C, у нас + будет три этапа: + </p> + <div class="informaltable"> + <table class="informaltable" border="1"> + <colgroup> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="300pt" align="left" /> + </colgroup> + <thead> + <tr> + <th align="center"> + Этап + </th> + <th align="center"> + Сборщик + </th> + <th align="center"> + Хост + </th> + <th align="center"> + Цель + </th> + <th align="left"> + Действие + </th> + </tr> + </thead> + <tbody> + <tr> + <td align="center"> + 1 + </td> + <td align="center"> + A + </td> + <td align="center"> + A + </td> + <td align="center"> + B + </td> + <td align="left"> + Сборка кросс-компилятора cc1 с использованием ccA на машине + A + </td> + </tr> + <tr> + <td align="center"> + 2 + </td> + <td align="center"> + A + </td> + <td align="center"> + B + </td> + <td align="center"> + C + </td> + <td align="left"> + Сборка кросс-компилятора cc2 с использованием cc1 на машине + A + </td> + </tr> + <tr> + <td align="center"> + 3 + </td> + <td align="center"> + B + </td> + <td align="center"> + C + </td> + <td align="center"> + C + </td> + <td align="left"> + Сборка компилятора ccC с использованием cc2 на машине B + </td> + </tr> + </tbody> + </table> + </div> + <p> + Затем все другие программы, необходимые для машины C, могут быть + скомпилированы с помощью cc2 на быстрой машине B. Обратите + внимание, что до тех пор, пока B не может запускать программы, + собранные для C, нет способа протестировать программы, пока не + будет запущена сама машина C. Например, чтобы запустить набор + тестов на ccC мы можем добавить четвертый этап: + </p> + <div class="informaltable"> + <table class="informaltable" border="1"> + <colgroup> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="300pt" align="left" /> + </colgroup> + <thead> + <tr> + <th align="center"> + Этап + </th> + <th align="center"> + Сборщик + </th> + <th align="center"> + Хост + </th> + <th align="center"> + Цель + </th> + <th align="left"> + Действие + </th> + </tr> + </thead> + <tbody> + <tr> + <td align="center"> + 4 + </td> + <td align="center"> + C + </td> + <td align="center"> + C + </td> + <td align="center"> + C + </td> + <td align="left"> + Пересобрать и протестировать ccC, используя ccC на машине C + </td> + </tr> + </tbody> + </table> + </div> + <p> + В приведенном выше примере только cc1 и cc2 являются + кросс-компиляторами, то есть они создают код для машины, отличной + от той, на которой они выполняются. Компиляторы ccA и ccC создают + код для машины, на которой они выполняются. Такие компиляторы + называются <span class="emphasis"><em>нативными</em></span> + компиляторами. + </p> + </div> + <div class="sect2" lang="ru" xml:lang="ru"> + <h2 class="sect2"> + <a id="lfs-cross" name="lfs-cross"></a>Реализация кросс-компиляции + для LFS + </h2> + <div class="admon note"> + <img alt="[Примечание]" src="../images/note.png" /> + <h3> + Примечание + </h3> + <p> + Все кросс-компилируемые пакеты в этой книге используют систему + сборки на основе autoconf. Система сборки на основе autoconf + принимает типы систем вида cpu-vendor-kernel-os, называемые + системным триплетом. Поскольку поле vendor часто не содержит + значения, autoconf позволяет вам опустить его. + </p> + <p> + Проницательный читатель может задаться вопросом, почему название + <span class="quote">«<span class="quote">триплет</span>»</span> + применяется к имени из четырех компонентов. Поле kernel и поле os + ранее применялись как единый элемент: <span class= + "quote">«<span class="quote">system</span>»</span>. Такая форма с + тремя полями все еще актуальна для некоторых систем, например, + <code class="literal">x86_64-unknown-freebsd</code>. Но две + системы могут использовать одно и то же ядро и все же быть + слишком разными, чтобы использовать одинаковый триплет для их + описания. Например, Android, работающий на мобильном телефоне + полностью отличается от Ubuntu, работающей на ARM64 сервере, хотя + они оба работают на одном и том же типе процессора (ARM64) и с + одним ядром (Linux). + </p> + <p> + Без слоя эмуляции вы не сможете запустить исполняемый файл c + сервера на мобильном телефоне и наоборот. Итак, поле <span class= + "quote">«<span class="quote">system</span>»</span> было разделено + на поля kernel и os, чтобы однозначно их интерпретировать. В + нашем примере Android обозначается как <code class= + "literal">aarch64-unknown-linux-android</code>, а Ubuntu + <code class="literal">aarch64-unknown-linux-gnu</code>. + </p> + <p> + Слово <span class="quote">«<span class= + "quote">триплет</span>»</span> сохранилось в лексиконе. Простой + способ определить триплет вашей машины — запустить скрипт + <span class="command"><strong>config.guess</strong></span>, + который входит в исходный код многих пакетов. Распакуйте + исходники binutils и запустите скрипт: <strong class= + "userinput"><code>./config.guess</code></strong>, обратите + внимание на вывод. Например, для 32-разрядного процессора Intel + вывод будет <span class= + "emphasis"><em>i686-pc-linux-gnu</em></span>. В 64-битной системе + это будет <span class= + "emphasis"><em>x86_64-pc-linux-gnu</em></span>. В большинстве + систем Linux используют еще более простую команду <span class= + "command"><strong>gcc -dumpmachine</strong></span>, которая + предоставит вам аналогичную информацию. + </p> + <p> + Вы также должны знать имя динамического компоновщика платформы, + часто называемого динамическим загрузчиком (не путать со + стандартным компоновщиком <span class= + "command"><strong>ld</strong></span>, который является частью + binutils). Динамический компоновщик, предоставляемый glibc, + находит и загружает общие библиотеки, необходимые программе, + подготавливает программу к запуску, а затем запускает ее. Имя + динамического компоновщика для 32-разрядной машины Intel — + <code class="filename">ld-linux.so.2</code>, а для 64-разрядных + систем — <code class="filename">ld-linux-x86-64.so.2</code>. + Надежный способ определить имя динамического компоновщика — + проверить случайный двоичный файл из хост-системы, выполнив + следующую команду: <strong class="userinput"><code>readelf -l + <имя исполняемого файла> | grep interpreter</code></strong> + и зафиксировать результат. Официальный источник, охватывающий все + платформы, находится в файле <code class= + "filename">shlib-versions</code> в корне дерева исходного кода + glibc. + </p> + </div> + <p> + Чтобы сымитировать кросс-компиляцию в LFS, имя триплета хоста + немного подкорректировали, изменив поле "vendor" в переменной + <code class="envar">LFS_TGT</code> таким образом, чтобы оно + указывало "lfs". Мы также используем параметр <em class= + "parameter"><code>--with-sysroot</code></em> при сборке + кросс-компоновщика и кросс-компилятора, чтобы сообщить им, где + найти необходимые файлы хоста. Это гарантирует, что ни одна из + программ, входящих в <a class="xref" href= + "../chapter06/chapter06.html" title= + "Глава 6. Кросс-Компиляция временных инструментов">Глава 6</a>, + не сможет ссылаться на библиотеки на машине сборки. Для корректной + работы, обязательны всего два этапа, еще один рекомендуется для + тестирования: + </p> + <div class="informaltable"> + <table class="informaltable" border="1"> + <colgroup> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="50pt" align="center" /> + <col width="300pt" align="left" /> + </colgroup> + <thead> + <tr> + <th align="center"> + Этап + </th> + <th align="center"> + Сборщик + </th> + <th align="center"> + Хост + </th> + <th align="center"> + Цель + </th> + <th align="left"> + Действие + </th> + </tr> + </thead> + <tbody> + <tr> + <td align="center"> + 1 + </td> + <td align="center"> + ПК + </td> + <td align="center"> + ПК + </td> + <td align="center"> + LFS + </td> + <td align="left"> + Сборка кросс-компилятора cc1 с использованием cc-pc на ПК + </td> + </tr> + <tr> + <td align="center"> + 2 + </td> + <td align="center"> + ПК + </td> + <td align="center"> + LFS + </td> + <td align="center"> + LFS + </td> + <td align="left"> + Сборка компилятора cc-lfs с использованием cc1 на ПК + </td> + </tr> + <tr> + <td align="center"> + 3 + </td> + <td align="center"> + LFS + </td> + <td align="center"> + LFS + </td> + <td align="center"> + LFS + </td> + <td align="left"> + Пересборка и тестирование cc-lfs, используя cc-lfs в lfs + </td> + </tr> + </tbody> + </table> + </div> + <p> + В приведенной выше таблице <span class="quote">«<span class= + "quote">ПК</span>»</span> означает, что команды выполняются на + компьютере с использованием уже установленного дистрибутива. + <span class="quote">«<span class="quote">В lfs</span>»</span> + означает, что команды выполняются в chroot-окружении. + </p> + <p> + Это еще не конец истории. Язык С - это не просто компилятор; также + он определяет стандартную библиотеку. В этой книге используется + библиотека GNU C под названием glibc (есть альтернативный вариант - + "musl"). Эта библиотека должна быть скомпилирована для машины lfs, + то есть с использованием кросс-компилятора cc1. Но сам компилятор + использует внутреннюю библиотеку, реализующую сложные инструкции, + недоступные в наборе инструкций ассемблера. Эта внутренняя + библиотека называется libgcc, и для полноценной работы ее + необходимо связать с библиотекой glibc! Кроме того, стандартная + библиотека для C++ (libstdc++) также должна быть связана с glibc. + Решение этой проблемы курицы и яйца состоит в том, чтобы сначала + собрать деградированную libgcc на основе cc1, в которой отсутствуют + некоторые функциональные возможности, такие как потоки и обработка + исключений, затем собрать glibc с использованием этого + деградированного компилятора (сама glibc не деградирована), а затем + собрать libstdc++. В этой последней библиотеке будет не хватать + некоторых функциональных возможностей libgcc. + </p> + <p> + Выводом из предыдущего абзаца является то, что cc1 не может собрать + полнофункциональную libstdc++ с деградированной libgcc, но это + единственный компилятор, доступный для сборки библиотек C/C++ на + этапе 2. Есть две причины, по которым мы не используем сразу + компилятор cc-lfs, собранный на этапе 2, для сборки этих библиотек. + </p> + <div class="itemizedlist"> + <ul> + <li class="listitem"> + <p> + Вообще говоря, cc-lfs не может работать на ПК (хост-системе). + Хотя триплеты для ПК и LFS совместимы друг с другом, + исполняемый файл для lfs должен зависеть от glibc-2.39; + хост-дистрибутив может использовать либо другую реализацию + libc (например, musl), либо предыдущий выпуск glibc + (например, glibc-2.13). + </p> + </li> + <li class="listitem"> + <p> + Даже если cc-lfs может работать на ПК, его использование на + ПК сопряжено с риском привязки к библиотекам ПК, так как + cc-lfs является родным компилятором. + </p> + </li> + </ul> + </div> + <p> + Поэтому, когда мы собираем gcc этап 2, мы даем указание системе + сборки пересобрать libgcc и libstdc++ с помощью cc1, но мы + связываем libstdc++ с новой пересобранной libgcc вместо старой, + деградированной. Это делает пересобранную библиотеку libstdc++ + полностью функциональной. + </p> + <p> + В <a class="xref" href="../chapter08/chapter08.html" title= + "Глава 8. Установка базового системного программного обеспечения">Глава 8</a> + (или <span class="quote">«<span class="quote">этап + 3</span>»</span>) собраны все пакеты, необходимые для системы LFS. + Даже если пакет уже был установлен в системе LFS в предыдущей + главе, мы все равно пересобираем пакет. Основная причина пересборки + этих пакетов состоит в том, чтобы сделать их стабильными: если мы + переустанавливаем пакет LFS в готовой системе LFS, содержимое + пакета должно совпадать с содержимым того же пакета при первой + установке в <a class="xref" href="../chapter08/chapter08.html" + title= + "Глава 8. Установка базового системного программного обеспечения">Глава 8</a>. + Временные пакеты, установленные в <a class="xref" href= + "../chapter06/chapter06.html" title= + "Глава 6. Кросс-Компиляция временных инструментов">Глава 6</a> + или <a class="xref" href="../chapter07/chapter07.html" title= + "Глава 7. Вход в окружение Chroot и создание дополнительных временных инструментов"> + Глава 7</a> не могут удовлетворять этому требованию, потому + что некоторые из них собраны без необязательных зависимостей и + autoconf не может выполнить некоторые проверки функций в <a class= + "xref" href="../chapter06/chapter06.html" title= + "Глава 6. Кросс-Компиляция временных инструментов">Глава 6</a> + из-за кросс-компиляции, в результате чего во временных пакетах + отсутствуют дополнительные функции или используются не оптимальные + процедуры кода. Кроме того, второстепенной причиной для пересборки + пакетов является выполнение тестов. + </p> + </div> + <div class="sect2" lang="ru" xml:lang="ru"> + <h2 class="sect2"> + <a id="other-details" name="other-details"></a>Другие детали + процесса + </h2> + <p> + Кросс-компилятор будет установлен в отдельный каталог <code class= + "filename">$LFS/tools</code>, так как он не будет частью конечной + системы. + </p> + <p> + Сначала устанавливается Binutils, потому что во время выполнения + команды <span class="command"><strong>configure</strong></span> gcc + и glibc выполняются различные тесты функций на ассемблере и + компоновщике, чтобы определить, какие программные функции следует + включить или отключить. Это важнее, чем может показаться на первый + взгляд. Неправильно настроенный gcc или glibc может привести к + незначительной поломке сборочных инструментов, где последствия + такой поломки могут проявиться ближе к концу сборки всего + дистрибутива. Сбой тестов обычно выявляет эту ошибку до того, как + будет выполнено много дополнительной работы. + </p> + <p> + Binutils устанавливает свой ассемблер и компоновщик в двух местах: + <code class="filename">$LFS/tools/bin</code> и <code class= + "filename">$LFS/tools/$LFS_TGT/bin</code>. Инструменты в одном + месте жестко связаны с другими. Важным аспектом компоновщика + является порядок поиска в библиотеке. Подробную информацию можно + получить от <span class="command"><strong>ld</strong></span>, + передав ей флаг <em class="parameter"><code>--verbose</code></em>. + Например, <span class="command"><strong>$LFS_TGT-ld --verbose | + grep SEARCH</strong></span> покажет текущие пути поиска и их + порядок. Он показывает, какие файлы связаны с помощью <span class= + "command"><strong>ld</strong></span>, путем компиляции фиктивной + программы и передачи параметра <em class= + "parameter"><code>--verbose</code></em> компоновщику. Например, + <span class="command"><strong>$LFS_TGT-gcc dummy.c -Wl,--verbose + 2>&1 | grep succeeded</strong></span> покажет все файлы, + успешно открытые во время компоновки. + </p> + <p> + Следующий устанавливаемый пакет — gcc. Пример того, что можно + увидеть во время запуска <span class= + "command"><strong>configure</strong></span>: + </p> + <pre class="screen"><code class= + "computeroutput">checking what assembler to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/as +checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</code></pre> + <p> + Это важно по причинам, упомянутым выше. Также здесь + демонстрируется, что сценарий настройки gcc не просматривает + значения переменной PATH, чтобы найти, какие инструменты + использовать. Однако во время фактической работы самого + <span class="command"><strong>gcc</strong></span> не обязательно + используются одни и те же пути поиска. Чтобы узнать, какой + стандартный компоновщик будет использовать <span class= + "command"><strong>gcc</strong></span>, запустите: <span class= + "command"><strong>$LFS_TGT-gcc -print-prog-name=ld</strong></span>. + </p> + <p> + Подробную информацию можно получить из <span class= + "command"><strong>gcc</strong></span>, передав ему параметр + <em class="parameter"><code>-v</code></em> при компиляции фиктивной + программы. Например, <span class="command"><strong>gcc -v + dummy.c</strong></span> покажет подробную информацию об этапах + препроцессора, компиляции и сборки, включая указанные в + <span class="command"><strong>gcc</strong></span> пути поиска и их + порядок. + </p> + <p> + Далее устанавливаются очищенные заголовочные файлы Linux API. Они + позволяют стандартной библиотеке C (Glibc) взаимодействовать с + функциями, предоставляемыми ядром Linux. + </p> + <p> + Следующий устанавливаемый пакет — glibc. Наиболее важными при + сборке glibc являются компилятор, бинарные инструменты и + заголовочные файлы ядра. С компилятором, как правило, не бывает + проблем, поскольку glibc всегда будет использовать компилятор, + указанный в параметре <em class= + "parameter"><code>--host</code></em>, переданный скрипту configure; + например, в нашем случае компилятором будет <span class= + "command"><strong>$LFS_TGT-gcc</strong></span>. С бинарными + инструментами и заголовки ядра может быть немного сложнее. Поэтому + мы не рискуем и используем доступные параметры конфигурации, чтобы + обеспечить правильный выбор. После запуска <span class= + "command"><strong>configure</strong></span> проверьте содержимое + файла <code class="filename">config.make</code> в каталоге + <code class="filename">сборки</code> на наличие всех важных + деталей. Обратите внимание на использование опции <em class= + "parameter"><code>CC="$LFS_TGT-gcc"</code></em> (с переменной + <code class="envar">$LFS_TGT</code>) для управления используемыми + бинарными инструментами и использование флагов <em class= + "parameter"><code>-nostdinc</code></em> и <em class= + "parameter"><code>-isystem</code></em> для управления включаемым + путем поиска компилятора. Эти пункты подчеркивают важный аспект + пакета glibc — он очень самодостаточен с точки зрения своего + механизма сборки и, как правило, не полагается на значения по + умолчанию. + </p> + <p> + Как было сказано выше, затем компилируется стандартная библиотека + C++, а затем в <a class="xref" href="../chapter06/chapter06.html" + title= + "Глава 6. Кросс-Компиляция временных инструментов">Глава 6</a> + все остальные программы, которым необходимо разрешить проблему + циклических зависимостей во время сборки. На этапе установки всех + этих пакетов используется переменная DESTDIR, для принудительной + установки в файловую систему LFS. + </p> + <p> + В конце <a class="xref" href="../chapter06/chapter06.html" title= + "Глава 6. Кросс-Компиляция временных инструментов">Глава 6</a> + устанавливается собственный компилятор lfs. Сначала собирается + binutils с той же переменной <code class="envar">DESTDIR</code>, + что и другие программы, затем повторно собирается gcc, без сборки + некоторых некритических библиотек. Из-за какой-то странной логики в + сценарии настройки GCC <code class="envar">CC_FOR_TARGET</code> + заканчивается как <span class="command"><strong>cc</strong></span>, + когда хост совпадает с целью, но отличается от системы сборки. + Поэтому значение <em class= + "parameter"><code>CC_FOR_TARGET=$LFS_TGT-gcc</code></em> явно + указывается в параметрах конфигурации. + </p> + <p> + После входа в среду chroot в <a class="xref" href= + "../chapter07/chapter07.html" title= + "Глава 7. Вход в окружение Chroot и создание дополнительных временных инструментов"> + Глава 7</a> первой задачей является установка libstdc++. Затем + выполняется установка временных программ, необходимых для + правильной работы тулчейна. С этого момента основной набор + инструментов является самодостаточным и автономным. В <a class= + "xref" href="../chapter08/chapter08.html" title= + "Глава 8. Установка базового системного программного обеспечения">Глава 8</a> + собираются, тестируются и устанавливаются окончательные версии всех + пакетов, необходимых для полнофункциональной системы. + </p> + </div> + </div> + <div class="navfooter"> + <ul> + <li class="prev"> + <a accesskey="p" href="introduction.html" title= + "Введение">Пред.</a> + <p> + Введение + </p> + </li> + <li class="next"> + <a accesskey="n" href="generalinstructions.html" title= + "Общие инструкции по компиляции">След.</a> + <p> + Общие инструкции по компиляции + </p> + </li> + <li class="up"> + <a accesskey="u" href="partintro.html" title= + "Важный предварительный материал">Наверх</a> + </li> + <li class="home"> + <a accesskey="h" href="../index.html" title= + "Линукс с нуля - Версия 12.1">Начало</a> + </li> + </ul> + </div> + </body> +</html> |