From ed06c0d730a5e9d0dde152fce42fc05eee466130 Mon Sep 17 00:00:00 2001
From: Poltern <2363951+Poltern@users.noreply.github.com>
Date: Fri, 23 Jun 2023 12:26:42 +0500
Subject: [PATCH] Translated part3intro
---
part3intro/generalinstructions.xml | 32 +++---
part3intro/introduction.xml | 26 ++---
part3intro/toolchaintechnotes.xml | 176 +++++++++++++++++++----------
3 files changed, 144 insertions(+), 90 deletions(-)
diff --git a/part3intro/generalinstructions.xml b/part3intro/generalinstructions.xml
index 7e8dcab..e542c99 100644
--- a/part3intro/generalinstructions.xml
+++ b/part3intro/generalinstructions.xml
@@ -18,11 +18,12 @@
На некоторые пакеты необходимо наложить патчи перед компиляцией,
метод использется тогда, когда исправление необходимо для решения проблем сборки.
- Патчи часто требются как в этой, так и в следующих главах, но иногда только в одном
- месте. Поэтому не беспокойтесь, если инструкции для скачанного патча отсутствуют.
- Предупреждающие сообщения о смещении или
- размытии также могут появляться при применении патча. Не
- обращайте внимания на эти предупреждения, когда патч был успешно применен.
+ Патчи часто требются как в этой, так и в следующих главах, но иногда, когда один
+ и тот же пакет собирается более одного раза, патч требуется не сразу. Поэтому не
+ беспокойтесь, если инструкции для скачанного патча отсутствуют.
+ Предупреждающие сообщения о смещении (offset) или
+ размытии (fuzz) также могут появляться при применении патча. Не
+ обращайте внимания на эти предупреждения, патч все равно успешно применен.
@@ -30,7 +31,8 @@
предупреждения. Это нормально, и их можно смело игнорировать. Предупреждения
появляются, например, когда используется устаревший, недопустимый синтаксис
C или C++. Стандарты C меняются довольно часто, и некоторые пакеты все еще
- используют более старый стандарт. Это не является проблемой, но вызывает предупреждения.
+ используют более старый стандарт. Это не является серьезной проблемой, но вызывает
+ появление предупреждений.
@@ -73,7 +75,7 @@
- Еще раз обратим внимание на процесс сборки:
+ Вот краткое описание процесса сборки:
@@ -83,7 +85,7 @@
/mnt/lfs/tools/. -->
- Перейдите в каталог с исходными кодами.
+ Перейдите в каталог /mnt/lfs/sources/.
Для каждого пакета:
@@ -94,20 +96,20 @@
убедитесь, что при извлечении
пакета вы залогинены под пользователем lfs.
- Все методы получения дерева исходного кода на месте сборки, кроме
- извлечения tar-архива, не поддерживаются. Примечательно, что использование
- cp -R для копирования дерева исходного кода в другое
- место может привести к уничтожению ссылок и временных меток в дереве
- исходного кода и вызвать сбой сборки.
+ Не используйте никаких методов, кроме команды tar,
+ для извлечения исходного кода. Примечательно, что использование команды
+ cp -R для копирования дерева исходного кода в другое
+ место может привести к уничтожению ссылок и меток времени в дереве исходного
+ кода и привести к сбою сборки.
Перейдите в каталог, созданный при извлечении пакета.
- Следуйте инструкциям книги по сборке пакета.
+ Следуйте инструкциям по сборке пакета.
- Вернитесь в исходный каталог.
+ Вернитесь в исходный каталог, когда сборка будет завершена.
Удалите извлеченный каталог, если не указано иное.
diff --git a/part3intro/introduction.xml b/part3intro/introduction.xml
index 6a386a8..aa48e82 100644
--- a/part3intro/introduction.xml
+++ b/part3intro/introduction.xml
@@ -10,23 +10,23 @@
Введение
- Эта часть разделена на три этапа: сначала соберите кросс-компилятор и
- связанные с ним библиотеки; во-вторых, используйте этот набор инструментов для
- создания нескольких утилит таким образом, чтобы изолировать их от основного
- дистрибутива; в-третьих, войдите в среду chroot, чтобы ещё больше улучшить
- изоляцию от хоста, и соберите остальные инструменты, необходимые для
- сборки окончательной системы.
+ Эта часть разделена на три этапа: во-первых, сборка кросс-компилятора и
+ связанных с ним библиотек; во-вторых, использование этого набора инструментов
+ для сборки нескольких утилит таким образом, чтобы изолировать их от основного
+ дистрибутива; в-третьих, вход в среду chroot (что ещё больше улучшает
+ изоляцию от хоста), и сборка оставшихся инструментов, необходимых для
+ создания конечной системы.
- С этой части начинается настоящая работа по созданию новой
+ Именно здесь начинается настоящая работа по сборке новой
системы. Требуется очень тщательно следить за тем, чтобы инструкции выполнялись
точно так, как они приведены в книге. Вы должны попытаться понять, что они делают,
- и каким бы ни было ваше желание закончить сборку, вы следует воздерживаться от
- слепого ввода команд, лучше читать документацию, когда есть что-то, что вы не
- понимаете. Кроме того, следите за выводом команд, отправляя их в файл с помощью
- утилиты tee. Это позволит провести диагностку, если что-то
+ и каким бы ни было ваше желание скорее закончить сборку, вам следует воздержаться от
+ слепого набора команд. Читайте документацию, если вы что-то не понимаете. Кроме
+ того, следите за результатом выполнения команд, отправляя лог в файл
+ с помощью утилиты tee. Это упрощает отладку, если что-то
пойдет не так.
- В следующем разделе дается техническое введение в процесс сборки, а следующий
- содержит очень важные общие инструкции по компиляции.
+ Следующий раздел представляет собой техническое введение в процесс сборки, а следующий
+ за ним, содержит очень важные общие инструкции по компиляции.
diff --git a/part3intro/toolchaintechnotes.xml b/part3intro/toolchaintechnotes.xml
index 3605478..3d97928 100644
--- a/part3intro/toolchaintechnotes.xml
+++ b/part3intro/toolchaintechnotes.xml
@@ -10,10 +10,10 @@
Технические примечания по сборочным инструментам
- В этом разделе объясняются технические детали, лежащие в основе сборки
- пакетов. Не обязательно сразу понимать все, что содержится в этом разделе.
- Большая часть этой информации станет более понятной после выполнения фактической
- сборки. К этому разделу можно обратиться в любое время по ходу процесса.
+ В этом разделе объясняются причины и некоторые технические детали, лежащие в
+ основе сборки пакетов. Не обязательно сразу понимать все, что содержится в этом
+ разделе. Большая часть этой информации станет более понятной после выполнения фактической
+ сборки. Возвращайтесь и перечитывайте этот раздел в любое время по ходу сборки.
Основная задача и состоит в том, чтобы создать временную
@@ -47,11 +47,11 @@
заслуживают отдельного раздела. Хотя этот раздел можно пропустить при первом
чтении, возвращение к нему позже будет полезно для полного понимания процесса.
- Давайте определим некоторые термины, используемые в этом контексте:
+ Давайте определим некоторые термины, используемые в этом контексте.
сборщик
- это машина, на которой мы создаем программы. Обратите внимание, что
+ это машина, на которой мы собираем программы. Обратите внимание, что
этот компьютер упоминается как хост
в других разделах.
@@ -71,7 +71,7 @@
В качестве примера представим следующий сценарий (иногда называемый
канадским крестом
): у нас есть компилятор на медленной
- машине, назовем ее машиной A, а компилятор ccA. У нас также есть быстрая
+ машине, назовем ее машиной A и компилятор ccA. У нас также есть быстрая
машина (B), но без компилятора, и мы хотим создать код для другой медленной
машины (C). Чтобы собрать компилятор для машины C, у нас будет три этапа:
@@ -89,25 +89,25 @@
1AAB
- сборка кросс-компилятора cc1 с использованием ccA на машине A
+ Сборка кросс-компилятора cc1 с использованием ccA на машине A
2ABC
- сборка кросс-компилятора cc2 с использованием cc1 на машине A
+ Сборка кросс-компилятора cc2 с использованием cc1 на машине A
3BCC
- сборка компилятора ccC с использованием cc2 на машине B
+ Сборка компилятора ccC с использованием cc2 на машине B
- Затем все другие программы, необходимые для машины C, могут быть
- скомпилированы с помощью cc2 на быстрой машине B. Обратите внимание, что
- если B не может запускать программы, созданные для C, нет способа
- протестировать собранные программы, пока не будет запущена сама машина C.
- Например, для тестирования ccC мы можем добавить четвертый этап:
+ Затем все другие программы, необходимые для машины C, могут быть
+ скомпилированы с помощью cc2 на быстрой машине B. Обратите внимание, что
+ до тех пор, пока B не может запускать программы, собранные для C, нет
+ способа протестировать программы, пока не будет запущена сама машина C.
+ Например, чтобы запустить набор тестов на ccC мы можем добавить четвертый этап:
@@ -123,7 +123,7 @@
4CCC
- пересобрать и протестировать ccC, используя себя на машине C
+ Пересобрать и протестировать ccC, используя ccC на машине C
@@ -140,39 +140,57 @@
Реализация кросс-компиляции для LFS
- Почти все системы сборки используют имена вида cpu-vendor-kernel-os,
- называемые машинным триплетом. Проницательный читатель может задаться
- вопросом, почему триплет
относится к имени из четырех компонентов.
- Так сложилось исторически: изначально для однозначного обозначения машины было
- достаточно трех компонентов, но с появлением новых машин и систем этого оказалось
- недостаточно. Слово триплет
осталось. Простой способ определить
+ Все кросс-компилируемые пакеты в этой книге используют систему сборки на основе
+ autoconf. Система сборки на основе autoconf принимает типы систем вида cpu-vendor-kernel-os,
+ называемые системным триплетом. Поскольку поле vendor часто не содержит значения,
+ autoconf позволяет вам опустить его.
+
+ Проницательный читатель может задаться вопросом, почему название триплет
+ применяется к имени из четырех компонентов. Поле kernel и поле os ранее применялись как единый
+ элемент: system
. Такая форма с тремя полями все еще актуальна для некоторых
+ систем, например, x86_64-unknown-freebsd. Но две системы могут использовать
+ одно и то же ядро и все же быть слишком разными, чтобы использовать одинаковый триплет для их
+ описания. Например, Android, работающий на мобильном телефоне полностью отличается от Ubuntu,
+ работающей на ARM64 сервере, хотя они оба работают на одном и том же типе процессора (ARM64) и
+ с одним ядром (Linux).
+
+ Без слоя эмуляции вы не сможете запустить исполняемый файл c сервера на мобильном телефоне
+ и наоборот. Итак, поле system
было разделено на поля kernel и os, чтобы однозначно
+ их интерпретировать. В нашем примере Android обозначается как
+ aarch64-unknown-linux-android, а Ubuntu
+ aarch64-unknown-linux-gnu.
+
+ Слово триплет
сохранилось в лексиконе. Простой способ определить
триплет вашей машины — запустить скрипт config.guess, который
входит в исходный код многих пакетов. Распакуйте исходники binutils и запустите
- скрипт: ./config.guess, обратите внимание на выходные данные.
+ скрипт: ./config.guess, обратите внимание на вывод.
Например, для 32-разрядного процессора Intel вывод будет
i686-pc-linux-gnu. В 64-битной системе это будет
- x86_64-pc-linux-gnu.
+ x86_64-pc-linux-gnu. В большинстве систем Linux используют еще более
+ простую команду gcc -dumpmachine, которая предоставит вам аналогичную
+ информацию.
- Также обратите внимание на название динамического компоновщика платформы,
+ Вы также должны знать имя динамического компоновщика платформы,
часто называемого динамическим загрузчиком (не путать со стандартным компоновщиком
ld, который является частью binutils). Динамический компоновщик,
- предоставляемый Glibc, находит и загружает общие библиотеки, необходимые программе,
+ предоставляемый glibc, находит и загружает общие библиотеки, необходимые программе,
подготавливает программу к запуску, а затем запускает ее. Имя динамического
компоновщика для 32-разрядной машины Intel — ld-linux.so.2, а для 64-разрядных систем — ld-linux-x86-64.so.2. Надежный способ определить
имя динамического компоновщика — проверить случайный двоичный файл из хост-системы,
выполнив следующую команду: readelf -l
- <name of binary> | grep interpreter и зафиксировать результат.
+ <имя исполняемого файла> | grep interpreter и зафиксировать результат.
Официальный источник, охватывающий все платформы, находится в файле
- shlib-versions в корне дерева исходного кода Glibc.
+ shlib-versions в корне дерева исходного кода glibc.
Чтобы сымитировать кросс-компиляцию в LFS, имя триплета хоста немного
- подкорректировали, изменив поле "vendor" в переменной LFS_TGT.
+ подкорректировали, изменив поле "vendor" в переменной LFS_TGT
+ таким образом, чтобы оно указывало "lfs".
Мы также используем параметр --with-sysroot при сборке
кросс-компоновщика и кросс-компилятора, чтобы сообщить им, где найти необходимые
- файлы хоста. Это гарантирует, что ни одна из программ, созданных в , не сможет ссылаться на библиотеки на машине
сборки. Для корректной работы, обязательны всего два этапа, еще один
рекомендуется для тестирования:
@@ -191,15 +209,15 @@
1ПКПКLFS
- сборка кросс-компилятора cc1 с использованием cc-pc на ПК
+ Сборка кросс-компилятора cc1 с использованием cc-pc на ПК
2ПКLFSLFS
- сборка компилятора cc-lfs с использованием cc1 на ПК
+ Сборка компилятора cc-lfs с использованием cc1 на ПК
3LFSLFSLFS
- пересборка и тестирование cc-lfs, используя себя в lfs
+ Пересборка и тестирование cc-lfs, используя cc-lfs в lfs
@@ -209,27 +227,61 @@
выполняются на компьютере с использованием уже установленного дистрибутива.
В lfs
означает, что команды выполняются в chroot-окружении.
- Теперь подробнее о кросс-компиляции: язык C - это не просто компилятор,
+ Это еще не конец истории. Язык С - это не просто компилятор;
также он определяет стандартную библиотеку. В этой книге используется библиотека
- GNU C под названием glibc. Эта библиотека должна быть скомпилирована для машины
+ GNU C под названием glibc (есть альтернативный вариант - "musl").
+ Эта библиотека должна быть скомпилирована для машины
lfs, то есть с использованием кросс-компилятора cc1. Но сам компилятор использует
внутреннюю библиотеку, реализующую сложные инструкции, недоступные в наборе
инструкций ассемблера. Эта внутренняя библиотека называется libgcc, и для
полноценной работы ее необходимо связать с библиотекой glibc! Кроме того,
стандартная библиотека для C++ (libstdc++) также должна быть связана с glibc.
Решение этой проблемы курицы и яйца состоит в том, чтобы сначала собрать
- деградированный libgcc на основе cc1, в котором отсутствуют некоторые функции,
- такие как потоки и обработка исключений, затем собрать glibc с использованием
- этого деградированного компилятора (сам glibc не деградирован), а затем собрать
- libstdc++. Но в этой библиотеке не будет хватать тех же функций, что и в libgcc.
+ деградированную libgcc на основе cc1, в которой отсутствуют некоторые функциональные
+ возможности, такие как потоки и обработка исключенийй, затем собрать glibc с использованием
+ этого деградированного компилятора (сама glibc не деградирована), а затем собрать
+ libstdc++. В этой последней библиотеке будет нехватать некоторых функциональных
+ возможностей libgcc.
- Это не конец истории: вывод из предыдущего абзаца заключается в том, что cc1
- не может собрать полнофункциональную libstdc++, но это единственный компилятор,
- доступный для сборки библиотек C/C++ на этапе 2! Конечно, компилятор, созданный на
- этапе 2, cc-lfs, сможет собрать эти библиотеки, но (1) система сборки GCC не
- знает, что ее можно использовать на ПК, и (2) ее использование на ПК сопряжено
- с риском привязки к библиотекам ПК, поскольку cc-lfs является родным компилятором.
- Поэтому мы должны собрать libstdc++ позже, в chroot.
+ Выводом из предыдущего абзаца является то, что cc1
+ не может собрать полнофункциональную libstdc++ с деградированной libgcc, но это
+ единственный компилятор, доступный для сборки библиотек C/C++ на этапе 2. Есть
+ две причины, по которым мы не используем сразу компилятор cc-lfs,
+ собранный на этапе 2, для сборки этих библиотек.
+
+
+
+
+ Вообще говоря, cc-lfs не может работать на ПК (хост-системе). Хотя триплеты для ПК и
+ LFS совместимы друг с другом, исполняемый файл для lfs должен зависеть от
+ glibc-&glibc-version;; хост-дистрибутив может использовать либо другую реализацию
+ libc (например, musl), либо предыдущий выпуск glibc (например, glibc-2.13).
+
+
+
+
+ Даже если cc-lfs может работать на ПК, его использование на ПК сопряжено с риском
+ привязки к библиотекам ПК, так как cc-lfs является родным компилятором.
+
+
+
+
+ Поэтому, когда мы собираем gcc этап 2, мы даем указание системе сборки пересобрать
+ libgcc и libstdc++ с помощью cc1, но мы связываем libstdc++ с новой пересобранной libgcc
+ вместо старой, деградированной. Это делает пересобранную библиотеку libstdc++
+ полностью функциональной.
+
+ В &ch-final; (или этап 3
) собраны все пакеты, необходимые для системы
+ LFS. Даже если пакет уже был установлен в системе LFS в предыдущей главе, мы все равно
+ пересобираем пакет. Основная причина пересборки этих пакетов состоит в том, чтобы сделать
+ их стабильными: если мы переустанавливаем пакет LFS в готовой системе LFS, содержимое пакета
+ должно совпадать с содержимым того же пакета при первой установке в &ch-final;. Временные
+ пакеты, установленные в &ch-tmp-cross; или &ch-tmp-chroot; не могут удовлетворять
+ этому требованию, потому что некоторые из них собраны без необязательных зависимостей и autoconf
+ не может выполнить некоторые проверки функций в &ch-tmp-cross; из-за кросс-компиляции, в результате
+ чего во временных пакетах отсутствуют дополнительные функции или используются неоптимальные
+ процедуры кода. Кроме того, второстепенной причиной для пересборки пакетов является выполнение
+ тестов.
@@ -241,10 +293,10 @@
class="directory">$LFS/tools, так как он не будет частью конечной системы.
Сначала устанавливается Binutils, потому что во время выполнения команды
- configure GCC и Glibc выполняются различные тесты функций
+ configure gcc и glibc выполняются различные тесты функций
на ассемблере и компоновщике, чтобы определить, какие программные функции
следует включить или отключить. Это важнее, чем может показаться на первый взгляд.
- Неправильно настроенный GCC или Glibc может привести к незначительной поломке
+ Неправильно настроенный gcc или glibc может привести к незначительной поломке
сборочных инструментов, где последствия такой поломки могут проявиться ближе
к концу сборки всего дистрибутива. Сбой тестов обычно выявляет эту ошибку до того,
как будет выполнено много дополнительной работы.
@@ -263,14 +315,14 @@
$LFS_TGT-gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded
покажет все файлы, успешно открытые во время компоновки.
- Следующий устанавливаемый пакет — GCC. Пример того, что можно увидеть
+ Следующий устанавливаемый пакет — gcc. Пример того, что можно увидеть
во время запуска configure:
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
Это важно по причинам, упомянутым выше. Также здесь демонстрируется, что
- сценарий настройки GCC не просматривает значеня переменной PATH, чтобы найти,
+ сценарий настройки gcc не просматривает значеня переменной PATH, чтобы найти,
какие инструменты использовать. Однако во время фактической работы самого
gcc не обязательно используются одни и те же пути поиска.
Чтобы узнать, какой стандартный компоновщик будет использовать gcc,
@@ -286,9 +338,9 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld
- Следующий устанавливаемый пакет — Glibc. Наиболее важными при сборке Glibc
+ Следующий устанавливаемый пакет — glibc. Наиболее важными при сборке glibc
являются компилятор, бинарные инструменты и заголовочные файлы ядра. С компилятором,
- как правило, не бывает проблем, поскольку Glibc всегда будет использовать компилятор,
+ как правило, не бывает проблем, поскольку glibc всегда будет использовать компилятор,
указанный в параметре --host, переданный скрипту configure;
например, в нашем случае компилятором будет $LFS_TGT-gcc. С бинарными
инструментами и заголовки ядра может быть немного сложнее. Поэтому мы не рискуем и
@@ -300,19 +352,19 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld$LFS_TGT) для управления используемыми бинарными
инструментами и использование флагов -nostdinc и
-isystem для управления включаемым путем поиска компилятора.
- Эти пункты подчеркивают важный аспект пакета Glibc — он очень самодостаточен
+ Эти пункты подчеркивают важный аспект пакета glibc — он очень самодостаточен
с точки зрения своего механизма сборки и, как правило, не полагается на значения по
умолчанию.
Как было сказано выше, затем компилируется стандартная библиотека C++, а
- затем в все программы, которые необходимо
- собрать. На этапе установки всех этих пакетов используется переменная DESTDIR,
- чтобы программы помещались в файловую систему LFS.
+ затем в все остальные программы, которым необходимо
+ разрешить проблему циклических зависимостей во время сборки. На этапе установки всех этих пакетов используется переменная DESTDIR,
+ для принудительной установки в файловую систему LFS.
В конце устанавливается
- собственный компилятор lfs. Сначала собирается binutils-pass2 с той же
- переменной DESTDIR, что и другие программы, затем собирается
- второй проход GCC, опуская libstdc++ и другие не важные библиотеки. Из-за
+ собственный компилятор lfs. Сначала собирается binutils с той же
+ переменной DESTDIR, что и другие программы, затем повторно собирается
+ gcc, без сборки некоторых некритических библиотек. Из-за
какой-то странной логики в сценарии настройки GCC CC_FOR_TARGET
заканчивается как cc, когда хост совпадает с целью, но
отличается от системы сборки. Поэтому значение
@@ -321,9 +373,9 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ldПосле входа в среду chroot в первой задачей является установка
- libstdc++. Затем выполняется установка временных программ, необходимых для
- правильной работы тулчейна. С этого момента основная цепочка инструментов является
- самодостаточной и автономной. В
+ libstdc++. Затем выполняется установка временных программ, необходимых для
+ правильной работы тулчейна. С этого момента основной набор инструментов является
+ самодостаточным и автономным. В
собираются, тестируются и устанавливаются окончательные версии всех пакетов,
необходимых для полнофункциональной системы.