зачем несколько проходов для сборки Linux From Scratch (LFS)?

Цель состоит в том, чтобы убедиться, что ваша сборка непротиворечива, независимо от того, какой компилятор вы используете для компиляции вашего компилятора (и, следовательно, какие ошибки есть у этого компилятора).

Допустим, вы собираете gcc 4.1 с gcc 3.2 (я назову этот gcc 3.2 "этап-0"). Люди, проводившие QA для gcc 4.1, не проверяли его корректную работу при сборке с помощью любого компилятора, отличного от gcc 4.1, поэтому необходимо сначала собрать gcc этапа 1, а затем использовать этот этап 1. для компиляции компилятора этапа 2, чтобы ошибки в компиляторе этапа 0 не влияли на конечный результат.

Затем процесс компиляции по умолчанию для gcc использует компилятор стадии 2 для создания компилятора стадии 3, и сравнивает два двоичных файла: любое различие между ними может использоваться как доказательство наличия ошибки.

(Конечно, это всего лишь эффективный механизм, позволяющий избежать непреднамеренных ошибок; см. классическую статью Кена Томпсона Размышления о доверии к доверию для обсуждения того, как преднамеренные ошибки могут пережить такие меры).

Это выходит за рамки gcc и охватывает всю цепочку инструментов, потому что везде применяются одни и те же принципы: не выполняйте дополнительный проход, чтобы убедиться, что вы строите соответствие для вашей целевой среды, тогда воспроизведение этих ошибок (и тестирование предлагаемых исправлений) становится намного сложнее, чем в противном случае. : Никто, у кого нет вашей (обычно нераскрытой) среды сборки, не обязательно воссоздаст ошибку!

Я знаю, что этот запрос немного устарел, но мне есть что добавить к ответам: разъяснение значения слова «бутстрап».

Основной причиной многоэтапной сборки является удаление всех остатков программ/конфигураций/библиотек хоста сборки из полученного программного обеспечения. Недостаточно скомпилировать свежее программное обеспечение. Вы также должны избегать любых ссылок на библиотеки хоста, интерфейсы ядра хоста (заголовки ядра), версии pkg хоста и все другие подобные зависимости от хост-системы.

Предположим, вы оказались мазохистом и захотели собрать Debian 4 на Fedora 27 (это должно быть возможным). Простое создание программного обеспечения потребовало бы ссылок на библиотеки 27 и другие вещи. И ваша результирующая система не будет работать, потому что эти вещи недоступны при установке окончательной системы.

LFS несколько упрощает процесс, создавая простые x86-to-x86 binutils и кросс-инструменты gcc на этапе 1, затем устанавливая заголовки для ядра, которое будет использоваться в окончательной системе, а затем glibc. Этап 2 (binutils и gcc) строится с использованием кросс-инструментов, что гарантирует, что программы/библиотеки/конфигурации хоста вообще не используются. Остальная часть цепочки инструментов (я называю ее этапом 3) создается с использованием инструментов этапа 2. Теперь можно построить последний этап (с небольшими изменениями) с гарантией того, что никакая часть узла сборки не будет использоваться или использоваться. , и что никакая часть цепочки инструментов не будет упоминаться или использоваться. Последний этап создается с использованием пути, похожего на PATH=/bin:/usr/bin:/tools/bin; таким образом, когда будут созданы окончательные инструменты, они будут использоваться вместо инструментов в цепочке инструментов.

Создание цепочки инструментов не для нетерпеливых. Мне потребовались месяцы, чтобы обновить систему сборки Smoothwall Express и используемые пакеты, потому что создание цепочки инструментов сопряжено с риском. Я сражался со многими драконами, балроками и гномами. Я часто ссылался на LFS, чтобы понять, как они это делают. В результате получается автоматизированная система сборки с повторным входом, которая создает весь дистрибутив без ссылок на хост-систему. В основном я строю его на Debian 8, но известно, что он строится на Gentoo, и предполагается, что он может строить сам на себе.