mirror of
https://github.com/Poltern/lfs-ru.git
synced 2024-10-18 11:50:21 +03:00
Translated part3intro
This commit is contained in:
Poltern
parent
f5f243bc93
commit
ed06c0d730
@ -18,11 +18,12 @@
|
||||
<listitem>
|
||||
<para>На некоторые пакеты необходимо наложить патчи перед компиляцией,
|
||||
метод использется тогда, когда исправление необходимо для решения проблем сборки.
|
||||
Патчи часто требются как в этой, так и в следующих главах, но иногда только в одном
|
||||
месте. Поэтому не беспокойтесь, если инструкции для скачанного патча отсутствуют.
|
||||
Предупреждающие сообщения о <emphasis>смещении</emphasis> или
|
||||
<emphasis>размытии</emphasis> также могут появляться при применении патча. Не
|
||||
обращайте внимания на эти предупреждения, когда патч был успешно применен.</para>
|
||||
Патчи часто требются как в этой, так и в следующих главах, но иногда, когда один
|
||||
и тот же пакет собирается более одного раза, патч требуется не сразу. Поэтому не
|
||||
беспокойтесь, если инструкции для скачанного патча отсутствуют.
|
||||
Предупреждающие сообщения о <emphasis>смещении (offset)</emphasis> или
|
||||
<emphasis>размытии (fuzz)</emphasis> также могут появляться при применении патча. Не
|
||||
обращайте внимания на эти предупреждения, патч все равно успешно применен.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -30,7 +31,8 @@
|
||||
предупреждения. Это нормально, и их можно смело игнорировать. Предупреждения
|
||||
появляются, например, когда используется устаревший, недопустимый синтаксис
|
||||
C или C++. Стандарты C меняются довольно часто, и некоторые пакеты все еще
|
||||
используют более старый стандарт. Это не является проблемой, но вызывает предупреждения.</para>
|
||||
используют более старый стандарт. Это не является серьезной проблемой, но вызывает
|
||||
появление предупреждений.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -73,7 +75,7 @@
|
||||
</important>
|
||||
|
||||
<important>
|
||||
<para>Еще раз обратим внимание на процесс сборки:</para>
|
||||
<para>Вот краткое описание процесса сборки:</para>
|
||||
|
||||
<orderedlist numeration="arabic" spacing="compact">
|
||||
<listitem>
|
||||
@ -83,7 +85,7 @@
|
||||
<filename class="directory">/mnt/lfs/tools/</filename>. --></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Перейдите в каталог с исходными кодами.</para>
|
||||
<para>Перейдите в каталог <filename class="directory">/mnt/lfs/sources/</filename>.</para>
|
||||
</listitem>
|
||||
<listitem id='buildinstr' xreflabel='Инструкции по сборке пакетов'>
|
||||
<para>Для каждого пакета:</para>
|
||||
@ -94,20 +96,20 @@
|
||||
<xref linkend="chapter-temporary-tools"/> убедитесь, что при извлечении
|
||||
пакета вы залогинены под пользователем lfs.</para>
|
||||
|
||||
<para>Все методы получения дерева исходного кода на месте сборки, кроме
|
||||
извлечения tar-архива, не поддерживаются. Примечательно, что использование
|
||||
<command>cp -R</command> для копирования дерева исходного кода в другое
|
||||
место может привести к уничтожению ссылок и временных меток в дереве
|
||||
исходного кода и вызвать сбой сборки.</para>
|
||||
<para>Не используйте никаких методов, кроме команды <command>tar</command>,
|
||||
для извлечения исходного кода. Примечательно, что использование команды
|
||||
<command>cp -R</command> для копирования дерева исходного кода в другое
|
||||
место может привести к уничтожению ссылок и меток времени в дереве исходного
|
||||
кода и привести к сбою сборки.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Перейдите в каталог, созданный при извлечении пакета.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Следуйте инструкциям книги по сборке пакета.</para>
|
||||
<para>Следуйте инструкциям по сборке пакета.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Вернитесь в исходный каталог.</para>
|
||||
<para>Вернитесь в исходный каталог, когда сборка будет завершена.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Удалите извлеченный каталог, если не указано иное.</para>
|
||||
|
||||
@ -10,23 +10,23 @@
|
||||
|
||||
<title>Введение</title>
|
||||
|
||||
<para>Эта часть разделена на три этапа: сначала соберите кросс-компилятор и
|
||||
связанные с ним библиотеки; во-вторых, используйте этот набор инструментов для
|
||||
создания нескольких утилит таким образом, чтобы изолировать их от основного
|
||||
дистрибутива; в-третьих, войдите в среду chroot, чтобы ещё больше улучшить
|
||||
изоляцию от хоста, и соберите остальные инструменты, необходимые для
|
||||
сборки окончательной системы.</para>
|
||||
<para>Эта часть разделена на три этапа: во-первых, сборка кросс-компилятора и
|
||||
связанных с ним библиотек; во-вторых, использование этого набора инструментов
|
||||
для сборки нескольких утилит таким образом, чтобы изолировать их от основного
|
||||
дистрибутива; в-третьих, вход в среду chroot (что ещё больше улучшает
|
||||
изоляцию от хоста), и сборка оставшихся инструментов, необходимых для
|
||||
создания конечной системы.</para>
|
||||
|
||||
<important><para>С этой части начинается настоящая работа по созданию новой
|
||||
<important><para>Именно здесь начинается настоящая работа по сборке новой
|
||||
системы. Требуется очень тщательно следить за тем, чтобы инструкции выполнялись
|
||||
точно так, как они приведены в книге. Вы должны попытаться понять, что они делают,
|
||||
и каким бы ни было ваше желание закончить сборку, вы следует воздерживаться от
|
||||
слепого ввода команд, лучше читать документацию, когда есть что-то, что вы не
|
||||
понимаете. Кроме того, следите за выводом команд, отправляя их в файл с помощью
|
||||
утилиты <command>tee</command>. Это позволит провести диагностку, если что-то
|
||||
и каким бы ни было ваше желание скорее закончить сборку, вам следует воздержаться от
|
||||
слепого набора команд. Читайте документацию, если вы что-то не понимаете. Кроме
|
||||
того, следите за результатом выполнения команд, отправляя лог в файл
|
||||
с помощью утилиты <command>tee</command>. Это упрощает отладку, если что-то
|
||||
пойдет не так.</para></important>
|
||||
|
||||
<para>В следующем разделе дается техническое введение в процесс сборки, а следующий
|
||||
содержит <emphasis role="strong">очень важные</emphasis> общие инструкции по компиляции.</para>
|
||||
<para>Следующий раздел представляет собой техническое введение в процесс сборки, а следующий
|
||||
за ним, содержит <emphasis role="strong">очень важные</emphasis> общие инструкции по компиляции.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -10,10 +10,10 @@
|
||||
|
||||
<title>Технические примечания по сборочным инструментам</title>
|
||||
|
||||
<para>В этом разделе объясняются технические детали, лежащие в основе сборки
|
||||
пакетов. Не обязательно сразу понимать все, что содержится в этом разделе.
|
||||
Большая часть этой информации станет более понятной после выполнения фактической
|
||||
сборки. К этому разделу можно обратиться в любое время по ходу процесса.</para>
|
||||
<para>В этом разделе объясняются причины и некоторые технические детали, лежащие в
|
||||
основе сборки пакетов. Не обязательно сразу понимать все, что содержится в этом
|
||||
разделе. Большая часть этой информации станет более понятной после выполнения фактической
|
||||
сборки. Возвращайтесь и перечитывайте этот раздел в любое время по ходу сборки.</para>
|
||||
|
||||
<para>Основная задача <xref linkend="chapter-cross-tools"/> и <xref
|
||||
linkend="chapter-temporary-tools"/> состоит в том, чтобы создать временную
|
||||
@ -47,11 +47,11 @@
|
||||
заслуживают отдельного раздела. Хотя этот раздел можно пропустить при первом
|
||||
чтении, возвращение к нему позже будет полезно для полного понимания процесса.</para>
|
||||
|
||||
<para>Давайте определим некоторые термины, используемые в этом контексте:</para>
|
||||
<para>Давайте определим некоторые термины, используемые в этом контексте.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>сборщик</term><listitem>
|
||||
<para>это машина, на которой мы создаем программы. Обратите внимание, что
|
||||
<para>это машина, на которой мы собираем программы. Обратите внимание, что
|
||||
этот компьютер упоминается как <quote>хост</quote> в других разделах.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -71,7 +71,7 @@
|
||||
|
||||
<para>В качестве примера представим следующий сценарий (иногда называемый
|
||||
<quote>канадским крестом</quote>): у нас есть компилятор на медленной
|
||||
машине, назовем ее машиной A, а компилятор ccA. У нас также есть быстрая
|
||||
машине, назовем ее машиной A и компилятор ccA. У нас также есть быстрая
|
||||
машина (B), но без компилятора, и мы хотим создать код для другой медленной
|
||||
машины (C). Чтобы собрать компилятор для машины C, у нас будет три этапа:</para>
|
||||
|
||||
@ -89,25 +89,25 @@
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>1</entry><entry>A</entry><entry>A</entry><entry>B</entry>
|
||||
<entry>сборка кросс-компилятора cc1 с использованием ccA на машине A</entry>
|
||||
<entry>Сборка кросс-компилятора cc1 с использованием ccA на машине A</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry><entry>A</entry><entry>B</entry><entry>C</entry>
|
||||
<entry>сборка кросс-компилятора cc2 с использованием cc1 на машине A</entry>
|
||||
<entry>Сборка кросс-компилятора cc2 с использованием cc1 на машине A</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry><entry>B</entry><entry>C</entry><entry>C</entry>
|
||||
<entry>сборка компилятора ccC с использованием cc2 на машине B</entry>
|
||||
<entry>Сборка компилятора ccC с использованием cc2 на машине B</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Затем все другие программы, необходимые для машины C, могут быть
|
||||
скомпилированы с помощью cc2 на быстрой машине B. Обратите внимание, что
|
||||
если B не может запускать программы, созданные для C, нет способа
|
||||
протестировать собранные программы, пока не будет запущена сама машина C.
|
||||
Например, для тестирования ccC мы можем добавить четвертый этап:</para>
|
||||
<para>Затем все другие программы, необходимые для машины C, могут быть
|
||||
скомпилированы с помощью cc2 на быстрой машине B. Обратите внимание, что
|
||||
до тех пор, пока B не может запускать программы, собранные для C, нет
|
||||
способа протестировать программы, пока не будет запущена сама машина C.
|
||||
Например, чтобы запустить набор тестов на ccC мы можем добавить четвертый этап:</para>
|
||||
|
||||
<informaltable align="center">
|
||||
<tgroup cols="5">
|
||||
@ -123,7 +123,7 @@
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>4</entry><entry>C</entry><entry>C</entry><entry>C</entry>
|
||||
<entry>пересобрать и протестировать ccC, используя себя на машине C</entry>
|
||||
<entry>Пересобрать и протестировать ccC, используя ccC на машине C</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -140,39 +140,57 @@
|
||||
<title>Реализация кросс-компиляции для LFS</title>
|
||||
|
||||
<note>
|
||||
<para>Почти все системы сборки используют имена вида cpu-vendor-kernel-os,
|
||||
называемые машинным триплетом. Проницательный читатель может задаться
|
||||
вопросом, почему <quote>триплет</quote> относится к имени из четырех компонентов.
|
||||
Так сложилось исторически: изначально для однозначного обозначения машины было
|
||||
достаточно трех компонентов, но с появлением новых машин и систем этого оказалось
|
||||
недостаточно. Слово <quote>триплет</quote> осталось. Простой способ определить
|
||||
<para>Все кросс-компилируемые пакеты в этой книге используют систему сборки на основе
|
||||
autoconf. Система сборки на основе autoconf принимает типы систем вида cpu-vendor-kernel-os,
|
||||
называемые системным триплетом. Поскольку поле vendor часто не содержит значения,
|
||||
autoconf позволяет вам опустить его.</para>
|
||||
|
||||
<para>Проницательный читатель может задаться вопросом, почему название <quote>триплет</quote>
|
||||
применяется к имени из четырех компонентов. Поле kernel и поле os ранее применялись как единый
|
||||
элемент: <quote>system</quote>. Такая форма с тремя полями все еще актуальна для некоторых
|
||||
систем, например, <literal>x86_64-unknown-freebsd</literal>. Но две системы могут использовать
|
||||
одно и то же ядро и все же быть слишком разными, чтобы использовать одинаковый триплет для их
|
||||
описания. Например, Android, работающий на мобильном телефоне полностью отличается от Ubuntu,
|
||||
работающей на ARM64 сервере, хотя они оба работают на одном и том же типе процессора (ARM64) и
|
||||
с одним ядром (Linux).</para>
|
||||
|
||||
<para>Без слоя эмуляции вы не сможете запустить исполняемый файл c сервера на мобильном телефоне
|
||||
и наоборот. Итак, поле <quote>system</quote> было разделено на поля kernel и os, чтобы однозначно
|
||||
их интерпретировать. В нашем примере Android обозначается как
|
||||
<literal>aarch64-unknown-linux-android</literal>, а Ubuntu
|
||||
<literal>aarch64-unknown-linux-gnu</literal>.</para>
|
||||
|
||||
<para>Слово <quote>триплет</quote> сохранилось в лексиконе. Простой способ определить
|
||||
триплет вашей машины — запустить скрипт <command>config.guess</command>, который
|
||||
входит в исходный код многих пакетов. Распакуйте исходники binutils и запустите
|
||||
скрипт: <userinput>./config.guess</userinput>, обратите внимание на выходные данные.
|
||||
скрипт: <userinput>./config.guess</userinput>, обратите внимание на вывод.
|
||||
Например, для 32-разрядного процессора Intel вывод будет
|
||||
<emphasis>i686-pc-linux-gnu</emphasis>. В 64-битной системе это будет
|
||||
<emphasis>x86_64-pc-linux-gnu</emphasis>.</para>
|
||||
<emphasis>x86_64-pc-linux-gnu</emphasis>. В большинстве систем Linux используют еще более
|
||||
простую команду <command>gcc -dumpmachine</command>, которая предоставит вам аналогичную
|
||||
информацию.</para>
|
||||
|
||||
<para>Также обратите внимание на название динамического компоновщика платформы,
|
||||
<para>Вы также должны знать имя динамического компоновщика платформы,
|
||||
часто называемого динамическим загрузчиком (не путать со стандартным компоновщиком
|
||||
<command>ld</command>, который является частью binutils). Динамический компоновщик,
|
||||
предоставляемый Glibc, находит и загружает общие библиотеки, необходимые программе,
|
||||
предоставляемый glibc, находит и загружает общие библиотеки, необходимые программе,
|
||||
подготавливает программу к запуску, а затем запускает ее. Имя динамического
|
||||
компоновщика для 32-разрядной машины Intel — <filename
|
||||
class="libraryfile">ld-linux.so.2</filename>, а для 64-разрядных систем — <filename
|
||||
class="libraryfile">ld-linux-x86-64.so.2</filename>. Надежный способ определить
|
||||
имя динамического компоновщика — проверить случайный двоичный файл из хост-системы,
|
||||
выполнив следующую команду: <userinput>readelf -l
|
||||
<name of binary> | grep interpreter</userinput> и зафиксировать результат.
|
||||
<имя исполняемого файла> | grep interpreter</userinput> и зафиксировать результат.
|
||||
Официальный источник, охватывающий все платформы, находится в файле
|
||||
<filename>shlib-versions</filename> в корне дерева исходного кода Glibc.</para>
|
||||
<filename>shlib-versions</filename> в корне дерева исходного кода glibc.</para>
|
||||
</note>
|
||||
|
||||
<para>Чтобы сымитировать кросс-компиляцию в LFS, имя триплета хоста немного
|
||||
подкорректировали, изменив поле "vendor" в переменной <envar>LFS_TGT</envar>.
|
||||
подкорректировали, изменив поле "vendor" в переменной <envar>LFS_TGT</envar>
|
||||
таким образом, чтобы оно указывало "lfs".
|
||||
Мы также используем параметр <parameter>--with-sysroot</parameter> при сборке
|
||||
кросс-компоновщика и кросс-компилятора, чтобы сообщить им, где найти необходимые
|
||||
файлы хоста. Это гарантирует, что ни одна из программ, созданных в <xref
|
||||
файлы хоста. Это гарантирует, что ни одна из программ, входящих в <xref
|
||||
linkend="chapter-temporary-tools"/>, не сможет ссылаться на библиотеки на машине
|
||||
сборки. Для корректной работы, обязательны всего два этапа, еще один
|
||||
рекомендуется для тестирования:</para>
|
||||
@ -191,15 +209,15 @@
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>1</entry><entry>ПК</entry><entry>ПК</entry><entry>LFS</entry>
|
||||
<entry>сборка кросс-компилятора cc1 с использованием cc-pc на ПК</entry>
|
||||
<entry>Сборка кросс-компилятора cc1 с использованием cc-pc на ПК</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry><entry>ПК</entry><entry>LFS</entry><entry>LFS</entry>
|
||||
<entry>сборка компилятора cc-lfs с использованием cc1 на ПК</entry>
|
||||
<entry>Сборка компилятора cc-lfs с использованием cc1 на ПК</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry><entry>LFS</entry><entry>LFS</entry><entry>LFS</entry>
|
||||
<entry>пересборка и тестирование cc-lfs, используя себя в lfs</entry>
|
||||
<entry>Пересборка и тестирование cc-lfs, используя cc-lfs в lfs</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -209,27 +227,61 @@
|
||||
выполняются на компьютере с использованием уже установленного дистрибутива.
|
||||
<quote>В lfs</quote> означает, что команды выполняются в chroot-окружении.</para>
|
||||
|
||||
<para>Теперь подробнее о кросс-компиляции: язык C - это не просто компилятор,
|
||||
<para>Это еще не конец истории. Язык С - это не просто компилятор;
|
||||
также он определяет стандартную библиотеку. В этой книге используется библиотека
|
||||
GNU C под названием glibc. Эта библиотека должна быть скомпилирована для машины
|
||||
GNU C под названием glibc (есть альтернативный вариант - "musl").
|
||||
Эта библиотека должна быть скомпилирована для машины
|
||||
lfs, то есть с использованием кросс-компилятора cc1. Но сам компилятор использует
|
||||
внутреннюю библиотеку, реализующую сложные инструкции, недоступные в наборе
|
||||
инструкций ассемблера. Эта внутренняя библиотека называется libgcc, и для
|
||||
полноценной работы ее необходимо связать с библиотекой glibc! Кроме того,
|
||||
стандартная библиотека для C++ (libstdc++) также должна быть связана с glibc.
|
||||
Решение этой проблемы курицы и яйца состоит в том, чтобы сначала собрать
|
||||
деградированный libgcc на основе cc1, в котором отсутствуют некоторые функции,
|
||||
такие как потоки и обработка исключений, затем собрать glibc с использованием
|
||||
этого деградированного компилятора (сам glibc не деградирован), а затем собрать
|
||||
libstdc++. Но в этой библиотеке не будет хватать тех же функций, что и в libgcc.</para>
|
||||
деградированную libgcc на основе cc1, в которой отсутствуют некоторые функциональные
|
||||
возможности, такие как потоки и обработка исключенийй, затем собрать glibc с использованием
|
||||
этого деградированного компилятора (сама glibc не деградирована), а затем собрать
|
||||
libstdc++. В этой последней библиотеке будет нехватать некоторых функциональных
|
||||
возможностей libgcc.</para>
|
||||
|
||||
<para>Это не конец истории: вывод из предыдущего абзаца заключается в том, что cc1
|
||||
не может собрать полнофункциональную libstdc++, но это единственный компилятор,
|
||||
доступный для сборки библиотек C/C++ на этапе 2! Конечно, компилятор, созданный на
|
||||
этапе 2, cc-lfs, сможет собрать эти библиотеки, но (1) система сборки GCC не
|
||||
знает, что ее можно использовать на ПК, и (2) ее использование на ПК сопряжено
|
||||
с риском привязки к библиотекам ПК, поскольку cc-lfs является родным компилятором.
|
||||
Поэтому мы должны собрать libstdc++ позже, в chroot.</para>
|
||||
<para>Выводом из предыдущего абзаца является то, что cc1
|
||||
не может собрать полнофункциональную libstdc++ с деградированной libgcc, но это
|
||||
единственный компилятор, доступный для сборки библиотек C/C++ на этапе 2. Есть
|
||||
две причины, по которым мы не используем сразу компилятор cc-lfs,
|
||||
собранный на этапе 2, для сборки этих библиотек.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Вообще говоря, cc-lfs не может работать на ПК (хост-системе). Хотя триплеты для ПК и
|
||||
LFS совместимы друг с другом, исполняемый файл для lfs должен зависеть от
|
||||
glibc-&glibc-version;; хост-дистрибутив может использовать либо другую реализацию
|
||||
libc (например, musl), либо предыдущий выпуск glibc (например, glibc-2.13).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Даже если cc-lfs может работать на ПК, его использование на ПК сопряжено с риском
|
||||
привязки к библиотекам ПК, так как cc-lfs является родным компилятором.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Поэтому, когда мы собираем gcc этап 2, мы даем указание системе сборки пересобрать
|
||||
libgcc и libstdc++ с помощью cc1, но мы связываем libstdc++ с новой пересобранной libgcc
|
||||
вместо старой, деградированной. Это делает пересобранную библиотеку libstdc++
|
||||
полностью функциональной.</para>
|
||||
|
||||
<para>В &ch-final; (или <quote>этап 3</quote>) собраны все пакеты, необходимые для системы
|
||||
LFS. Даже если пакет уже был установлен в системе LFS в предыдущей главе, мы все равно
|
||||
пересобираем пакет. Основная причина пересборки этих пакетов состоит в том, чтобы сделать
|
||||
их стабильными: если мы переустанавливаем пакет LFS в готовой системе LFS, содержимое пакета
|
||||
должно совпадать с содержимым того же пакета при первой установке в &ch-final;. Временные
|
||||
пакеты, установленные в &ch-tmp-cross; или &ch-tmp-chroot; не могут удовлетворять
|
||||
этому требованию, потому что некоторые из них собраны без необязательных зависимостей и autoconf
|
||||
не может выполнить некоторые проверки функций в &ch-tmp-cross; из-за кросс-компиляции, в результате
|
||||
чего во временных пакетах отсутствуют дополнительные функции или используются неоптимальные
|
||||
процедуры кода. Кроме того, второстепенной причиной для пересборки пакетов является выполнение
|
||||
тестов.
|
||||
|
||||
</sect2>
|
||||
|
||||
@ -241,10 +293,10 @@
|
||||
class="directory">$LFS/tools</filename>, так как он не будет частью конечной системы.</para>
|
||||
|
||||
<para>Сначала устанавливается Binutils, потому что во время выполнения команды
|
||||
<command>configure</command> GCC и Glibc выполняются различные тесты функций
|
||||
<command>configure</command> gcc и glibc выполняются различные тесты функций
|
||||
на ассемблере и компоновщике, чтобы определить, какие программные функции
|
||||
следует включить или отключить. Это важнее, чем может показаться на первый взгляд.
|
||||
Неправильно настроенный GCC или Glibc может привести к незначительной поломке
|
||||
Неправильно настроенный gcc или glibc может привести к незначительной поломке
|
||||
сборочных инструментов, где последствия такой поломки могут проявиться ближе
|
||||
к концу сборки всего дистрибутива. Сбой тестов обычно выявляет эту ошибку до того,
|
||||
как будет выполнено много дополнительной работы.
|
||||
@ -263,14 +315,14 @@
|
||||
<command>$LFS_TGT-gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</command>
|
||||
покажет все файлы, успешно открытые во время компоновки.</para>
|
||||
|
||||
<para>Следующий устанавливаемый пакет — GCC. Пример того, что можно увидеть
|
||||
<para>Следующий устанавливаемый пакет — gcc. Пример того, что можно увидеть
|
||||
во время запуска <command>configure</command>:</para>
|
||||
|
||||
<screen><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</computeroutput></screen>
|
||||
|
||||
<para>Это важно по причинам, упомянутым выше. Также здесь демонстрируется, что
|
||||
сценарий настройки GCC не просматривает значеня переменной PATH, чтобы найти,
|
||||
сценарий настройки gcc не просматривает значеня переменной PATH, чтобы найти,
|
||||
какие инструменты использовать. Однако во время фактической работы самого
|
||||
<command>gcc</command> не обязательно используются одни и те же пути поиска.
|
||||
Чтобы узнать, какой стандартный компоновщик будет использовать <command>gcc</command>,
|
||||
@ -286,9 +338,9 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute
|
||||
стандартной библиотеке C (Glibc) взаимодействовать с функциями, предоставляемыми
|
||||
ядром Linux.</para>
|
||||
|
||||
<para>Следующий устанавливаемый пакет — Glibc. Наиболее важными при сборке Glibc
|
||||
<para>Следующий устанавливаемый пакет — glibc. Наиболее важными при сборке glibc
|
||||
являются компилятор, бинарные инструменты и заголовочные файлы ядра. С компилятором,
|
||||
как правило, не бывает проблем, поскольку Glibc всегда будет использовать компилятор,
|
||||
как правило, не бывает проблем, поскольку glibc всегда будет использовать компилятор,
|
||||
указанный в параметре <parameter>--host</parameter>, переданный скрипту configure;
|
||||
например, в нашем случае компилятором будет <command>$LFS_TGT-gcc</command>. С бинарными
|
||||
инструментами и заголовки ядра может быть немного сложнее. Поэтому мы не рискуем и
|
||||
@ -300,19 +352,19 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute
|
||||
(с переменной <envar>$LFS_TGT</envar>) для управления используемыми бинарными
|
||||
инструментами и использование флагов <parameter>-nostdinc</parameter> и
|
||||
<parameter>-isystem</parameter> для управления включаемым путем поиска компилятора.
|
||||
Эти пункты подчеркивают важный аспект пакета Glibc — он очень самодостаточен
|
||||
Эти пункты подчеркивают важный аспект пакета glibc — он очень самодостаточен
|
||||
с точки зрения своего механизма сборки и, как правило, не полагается на значения по
|
||||
умолчанию.</para>
|
||||
|
||||
<para>Как было сказано выше, затем компилируется стандартная библиотека C++, а
|
||||
затем в <xref linkend="chapter-temporary-tools"/> все программы, которые необходимо
|
||||
собрать. На этапе установки всех этих пакетов используется переменная DESTDIR,
|
||||
чтобы программы помещались в файловую систему LFS.</para>
|
||||
затем в <xref linkend="chapter-temporary-tools"/> все остальные программы, которым необходимо
|
||||
разрешить проблему циклических зависимостей во время сборки. На этапе установки всех этих пакетов используется переменная DESTDIR,
|
||||
для принудительной установки в файловую систему LFS.</para>
|
||||
|
||||
<para>В конце <xref linkend="chapter-temporary-tools"/> устанавливается
|
||||
собственный компилятор lfs. Сначала собирается binutils-pass2 с той же
|
||||
переменной <envar>DESTDIR</envar>, что и другие программы, затем собирается
|
||||
второй проход GCC, опуская libstdc++ и другие не важные библиотеки. Из-за
|
||||
собственный компилятор lfs. Сначала собирается binutils с той же
|
||||
переменной <envar>DESTDIR</envar>, что и другие программы, затем повторно собирается
|
||||
gcc, без сборки некоторых некритических библиотек. Из-за
|
||||
какой-то странной логики в сценарии настройки GCC <envar>CC_FOR_TARGET</envar>
|
||||
заканчивается как <command>cc</command>, когда хост совпадает с целью, но
|
||||
отличается от системы сборки. Поэтому значение
|
||||
@ -321,9 +373,9 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute
|
||||
|
||||
<para>После входа в среду chroot в <xref
|
||||
linkend="chapter-chroot-temporary-tools"/> первой задачей является установка
|
||||
libstdc++. Затем выполняется установка временных программ, необходимых для
|
||||
правильной работы тулчейна. С этого момента основная цепочка инструментов является
|
||||
самодостаточной и автономной. В <xref linkend="chapter-building-system"/>
|
||||
libstdc++. Затем выполняется установка временных программ, необходимых для
|
||||
правильной работы тулчейна. С этого момента основной набор инструментов является
|
||||
самодостаточным и автономным. В <xref linkend="chapter-building-system"/>
|
||||
собираются, тестируются и устанавливаются окончательные версии всех пакетов,
|
||||
необходимых для полнофункциональной системы.</para>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user