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++. Затем выполняется установка временных программ, необходимых для + правильной работы тулчейна. С этого момента основной набор инструментов является + самодостаточным и автономным. В собираются, тестируются и устанавливаются окончательные версии всех пакетов, необходимых для полнофункциональной системы.