diff options
| author | Sn4il <sn4il@thedroth.rocks> | 2024-03-06 10:25:41 +0300 |
|---|---|---|
| committer | Sn4il <sn4il@thedroth.rocks> | 2024-03-06 10:25:41 +0300 |
| commit | 5a6834585c43296c2207f5f251d3d5c237c7c8d2 (patch) | |
| tree | 5c3f9adc4c5fd0b3bdc3b017b021a36016c0f15b /lfs-12.0-sysv/partintro/toolchaintechnotes.html | |
| parent | 2b6ec04f001bbdf660476a1275d90075d746833c (diff) | |
| download | sn4il-site-5a6834585c43296c2207f5f251d3d5c237c7c8d2.tar.gz sn4il-site-5a6834585c43296c2207f5f251d3d5c237c7c8d2.zip | |
Update LFS mirror
Diffstat (limited to 'lfs-12.0-sysv/partintro/toolchaintechnotes.html')
| -rw-r--r-- | lfs-12.0-sysv/partintro/toolchaintechnotes.html | 743 |
1 files changed, 0 insertions, 743 deletions
diff --git a/lfs-12.0-sysv/partintro/toolchaintechnotes.html b/lfs-12.0-sysv/partintro/toolchaintechnotes.html deleted file mode 100644 index 998168b..0000000 --- a/lfs-12.0-sysv/partintro/toolchaintechnotes.html +++ /dev/null @@ -1,743 +0,0 @@ -<!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 V1.79.1" /> - <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.0"> - <div class="navheader"> - <h4> - Линукс с нуля - Версия 12.0 - </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.0">Начало</a> - </li> - </ul> - </div> - <div class="sect1" lang="en" xml:lang="en"> - <h1 class="sect1"> - <a id="ch-tools-toolchaintechnotes" name= - "ch-tools-toolchaintechnotes"></a>ii. Технические примечания по - сборочным инструментам - </h1> - <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="en" xml:lang="en"> - <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="en" xml:lang="en"> - <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.38; - хост-дистрибутив может использовать либо другую реализацию - 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="en" xml:lang="en"> - <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.0">Начало</a> - </li> - </ul> - </div> - </body> -</html> |