Long read. #bootstrap

Я думаю, не секрет, что мне очень интересны системы сборки, в самом разнообразном виде. Настолько, что у меня есть:

1) Своя система сборки для С++ кода
* https://github.com/pg83/zm
* https://github.com/pg83/zm/blob/master/tp/libs/python/src/z.make

2) И своя система сборки OSS пакетов. Для Darwin и для Linux, для последнего это не только система пакетов, но и полноценный дистрибутив:
* https://github.com/pg83/mix
* https://github.com/pg83/mix/blob/main/pkgs/dev/lang/python3/package.sh (самый большой сборочный пакет, потому что собрать статически слинкованный Питон - совершенно нетривиальная задача)

Об этих проектах я еще буду рассказывать, особенно про второй. Сейчас я их привел для понимания того, что тема сборки, дистросроения, бутстрапа, мне очень интересны.

Сегодня я хочу поговорить про задачу бутстрапа.

Что это такое? Представьте себе, что вы попали на необитаемый остров, у вас есть пустой компьютер(без ОС), и компакт-диск с исходниками программ. Нужно из этого получить рабочую ОС, чтобы на необитаемом острове было не так скучно(стюардесса на необитаемый остров с нами не попала).

Эта задача имеет следующие аспекты:

1) Исторический. Как вообще проходил путь от компьютера с перфокартами до современных рабочих станций и планшетов?
2) Сугубо практический - как развернуть дистрибутив, имея максимально малый возможный бинарный seed. Вот очень интересное исследование, как проложить путь от минимального гипервизора в 200 инструкций до современного дистрибутива Linux - https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
3) Безопасность. Воспроизводимая сборка с минимальным бинарным seed нужна, чтобы быть уверенным, что в софте нет закладок. Например, небезызвестная атака Томпсона: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf . Очень смешной вариант - https://www.quora.com/What-is-a-coders-worst-nightmare/answer/Mick-Stute?share=1 Да и просто понимать, что твоя сборка Alacritty собрана из исходников с github, и не содержит в себе трояна или какой другой жести, очень ценно.

Я стараюсь не держать у себя софта, для которого нельзя протянуть вот такую вот цепочку from ground truth.

В интернетах есть несколько community, которых эта задача тоже беспокоит:

1) https://bootstrappable.org/
2) https://guix.gnu.org/ (очень сильно упарываются по bootstrap)
3) https://nixos.org/ (в меньшей степени, не стесняются использовать бинарные сборки Rust, например)

Товарищи из Guix даже разработали пару специализированных языков для первоначального bootstrap(https://www.gnu.org/software/mes/, https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/) У guix, правда, есть другие свои заморочки, поэтому не могу его рекомендовать для повседневного использования. Nix в этом отношении интереснее, я его использовал как пакетный менеджер для любого Linux, Darwin, пока не завершил задачу bootstrap своего дистрибутива.

Что стоит еще рассказать про тему bootstrap:
* Далеко не все языки можно bootstrap. Это значит, что для некоторых языков нужен большой изначальный blob неизвестного качества. Я такие языки стараюсь не использовать(https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html).
* Java бутстрапнули совсем недавно(https://bootstrappable.org/projects/jvm-languages.html). Систему сборки для нее(gradle) до сих пор не.
* Rust, с моей точки зрения, с натяжкой bootstrapable. Потому что: #mrustc
1) Для сборки n-ой версии нужна n-1 версия. Это очень сильно увеличивает длину цепочки bootstrap. Порядка 20 сборок на текущий момент?
2) Исходники первых версий на standard ml лежат неизвестно где. Bootstrap возможен только с сиспользованием стороннего продукта(https://github.com/thepowersgang/mrustc)
3) На Apple M1 цепочку пока повторить не получается
* У Go с bootstrap все хорошо, авторы поддерживают версию 1.4, последнюю на С. С ее помощью можно собрать современный Go. Так же существует gccgo.
* У Lisp все тоже очень хорошо. Скажем, цепочку от интерпретируемого ECL до компилируемого SBCL на Apple M1 я протянул за час.

https://github.com/thepowersgang/mrustc #mrustc #bootstrap

Проект начал приземлять поддержку Rust 1.54. Вы себе не представляете, какое это событие для Rust bootstrap, потому что для bootstrap current версии требуется уже несколько десятков пересборок, от версии 1.29 до current.

Господин John Hodge, конечно, поражает, - в одно рыло тащить проект несколько лет, постоянно поддерживая новые фичи из mainstream(ну, кроме borrow checker). Упоротость в лучшем виде, like.

https://lwn.net/Articles/771355/

Сам текст не очень интересен, интересны комментарии. Там все - пользователи, мейнтейнеры debian, разработчики Rust - обсуждают сложности Rust bootstrap. Интересно, как сталкиваются разные точки зрения("вы нам мешаете поддерживать дистрибутив в рабочем состоянии" vs. "нет, это вы нам мешаете бежать быстрее").

———
https://medium.com/@pv.safronov/moscow-state-university-network-built-by-students-211539855cf9

"That’s when you had to resort to the last option: using lockpicks. Yes, you heard it correctly. Network engineers had lockpicks and were trained to use them."

"Then one engineer sways the cable while another one is catching it downstairs"

Шваброй, ага.

Божечки, какая ностальгия... Провода, торчащие из окон... forum.b.gz.ru... glebius, patnik... Где моя молодость?

———
Из будней бустрапера. Я бутстрапнул bison && flex. Это потребовало, суммарно, около 15 пересборок разных версий lex, flex, bison, byacc. Но об этой волшебной цепочке немного позже, а сегодня за bison.

Bison - это кошмар бутстрапера. Потому что у него N версия легко может не собираться N - 1:

YACC     src/parse-gram.c
bison-3.8.2/src/parse-gram.y:155.1-7: error:
  invalid directive: '%header'
  155 | %header
      | ^~~~~~~

И в репозитории bison уже лежит готовый файлик, который, сцуко, сделан той же версией bison, что лежит в репозитории:

pg@:~bison-3.8.2/src head -n 1 parse-gram.c
/* A Bison parser, made by GNU Bison 3.8.2.  */

Знаете, когда я клал версии с 4 по 7, я подумал, "ну с кем не бывает", но когда вчера клал восьмую, и снова наткнулся на то, что она требует сама себя для сборки(а значит, нетривиального патчинга исходников), я начал думать, что они это специально.

#svg

С иконками, я, конечно, намучался.

* Пути к дефолтным иконкам в тулкитах.
* Какие иконки должны быть.
* Часть иконок в Adwaita лежит в png, часть - в svg, эти множества частично пересекаются. Что выберет то или иное приложение, одному (хз знает кому) известно. В svg лежат ЧБ иконки, в png - цветные.
* Загрузка svg устроена через плагин для gdk-pixbuf. Плагины для него устроены самым ненатуральным образом из всех мне известных(постараюсь написать про то, как извращенно разработчики устраивают загрузку своих плагинов). К сожалению, последняя версия этого плагина, не переписанная на Rust, не очень корректно рендерит последние иконки от Adwaita.
* Отладка "чего там реально загружается" через strace не очень помогает, так как каждая папка с иконками должна содержать индекс.

Так и живем - для качественного рендеринга в png требуется inkscape, для некачественного на лету - Rust.

К сожалению, компилятор Rust у меня сейчас даже не запускается, потому что он принципиально не может быть слинкован статически.

Вся надежда на https://github.com/thepowersgang/mrustc #mrustc, чувак все ближе и ближе к тому, чтобы поддержкать 1.54. Понятное дело, что без borrow checker, но кому оно надо не в процессе разработки? У него своя реализация proc macro(по понятным причинам), не требующая подгрузки .so в компилятор.

Я сейчас остановился на svg иконках с не совсем корректным рендерингом, потому что облизывать Epiphany уже поднадоело(https://wiki.gnome.org/Apps/Web). Надо посмотреть, что ждет на пути сборки Chromium.

Кстати, я почти победил тиринг в Epiphany. Для этого я собрал webkit web process(который занимается непосредственно рендерингом) на gtk4, в котором все лучше с поддержкой opengl/vulkan канвы, а сам браузер с gtk3. Потому что Igalia уже портировала WebKIT на gkt4, а сам браузер - еще нет. Думаю, Igalia подавились бы чем-нибудь на радостях, узнав, что я так делаю. #igalia

Теорминимум по #bootstrap

Разные команды вкладывают в это понятие очень разные смыслы.

Кто-то - что в процессе сборки не должны участвовать бинарные блобы(за исключением возможного минимума). Понятие "бинарный" часто не конкретизируется. Java VM, python pickle - чаще всего "бинарные блобы". По мне, так программы для "раннебутстрапного" forth от бинарных блобов не отличимы, но это никого не останавливает.

Кто-то идет еще дальше, и считает, что автосгенеренные исходники использовать тоже нельзя. Эти люди занимаются бутстрапом flex/bison/ragel/etc. К сожалению, на этом пути лежит пропасть и бездна - configure скрипты. Уважаемым коллегам или приходится переписывать систему сборки части кода, или бутстрепать код в бездну веков. Это, например, GUIX.

Кто-то больше всего печется о "чистоте" результата. Ну, чтобы рандомный Васян мог воспроизвести md5-equal result. Используется ли при этом бинарный seed, или нет, коллег особо не волнует. Это, например, Nix.

Я тут стараюсь придерживаться прагматичной стороны - я не перестраиваю configure на ранних этапах bootstrap, но когда у меня готов perl, начинаю перестраивать. Типа, получить 95% результата за 5% денег. Если у меня 1000 пакетов, и в 995 из них я убираю сгенеренные файлы, поверхность для атаки я уменьшаю многократно, и вполне достаточно для практических целей. Бинарный seed я, фактически, использовать не могу, потому что чаще всего он рассчитывает на наличие glibc.

Еще интересная дихотомия - какой язык использовать в качестве "изначального". Чаще всего это компилятор С, потому что достаточно высокороуровнево(не надо мудохаться с ассемблером и гипервизором в кольце 0), можно дотащить цепочку, куда угодно, большинство системного кода написано на С.

Я тяну цепочку с С++, потому что поддерживаю Darwin, а там единственный компилятор, который умеет рожать Mach-O - это clang. Есть проекты, которые тащут tcc/scc под Mach-O, я с удовольствием за ними слежу(потому что С++, это, конечно, многовато).

Наверняка есть попытки затащить эту цепочку с Rust, но я о чем-то таком успешном пока не слышал. В принципе, все для этого есть - uutils, наверняка есть простой компилятор С на Rust, шелл точно есть. Если тащить с Rust, то, конечно, с собой нельзя брать Cargo. Весь смысл теряется, если добавить cargo в seed, да и не спортивно это. Как #mrustc тянет cargo через свой minicargo - это же песня.

Новости одной строкой: #mrustc https://github.com/thepowersgang/mrustc умеет в rust 1.54.0.

Надо бы им попробовать собрать не rustc, а что-то полезное. В отличие от mainstream rustc, оно умеет в процедурные макросы без загрузки .so в адресное пространство rustc.

Пробую собирать #mrustc, https://github.com/thepowersgang/mrustc

Автор этого проекта, очевидно, разбирается в компиляторах, но совершенно не разбирается в системах сборки.

Его система сборки - это 4 Makefile, котрые рекурсивно вызывают друг друга, модифицируя аргументы и переменные среды.

https://github.com/thepowersgang/mrustc/blob/master/build-1.54.0.sh - главный драйвер сборки, вызывает make 7 раз, с разными Makefile, и аргументами(и каждый из этих вызовов еще рекурсивно дергает make!)

Короче, я все это выкинул нахуй, и написал все нужные вызовы команд руками, заодно разобрался, как это все работает.

Пока получилось:

* собрать компилятор
* собрать minicargo
* с их помощью собрать cargo(1) из mainstream исходников

Дальше цепочка bootstrap предполагает:

* mrustc + minicargo -> rustc(1)
* minicargo + rustc(1) -> std(2)
* std(2) + cargo(1) + rustc(1) -> rustc(2), cargo(2)

Очевидно, что дальше первого пункта зайти не получится, не решив кардинальную проблему rustc - загрузку .so во время работы.

То есть, получить rustc(1), cargo(1) я могу, а вот дальше с ними сделать ничего не выйдет.

Я, как и собирался, попробовал собрать какой-нить сторонний софт с помощью mrustc + minicargo, но, увы, пока он заточен только на сборку самого rust.

Что я могу заметить по процессу?

Разработчики rust, конечно, пионеры, с завышенным ЧСВ. Иначе я никак не могу объяснить вот это вот говно - https://github.com/rust-lang/libc/tree/master/src/unix/linux_like/linux

Поштырьте по исходникам, и оцените, как изящно эти долбоебы обертывают libc. Фактически, они хардкодят оффсеты и размеры структур.

Нормальный человек нагенерил бы кучу setter/getter для структур, типа:

int struct_stat_get_inode(struct stat* s) {
    return s->st_ino;
}

И скомпилял бы это С-компилятором, чтобы вообще не думать о layout этого С-шного хлама.

Но это же не по пацански, и вообще, у нас комплексы лапки, и нужно сделать вид, что C тут и рядом не стояло, поэтому мы построим все на Rust: https://github.com/rust-lang/libc/blob/master/src/unix/linux_like/linux/musl/b64/aarch64/mod.rs#L10 Копипаста под все платформы и возможность разъехаться - не, не слышали.

А потом нормальный человек будет искать, где у него проезд по памяти, потому что код собрался под glibc вариант, а используется musl.

True story, я искал, в качестве фикса mrustc у меня принудительно собирает под musl, потому что куда это в нем передать, я не нашел.https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mrustc/mix.sh#L41

Ну и вендоринг C/C++ исходников(openssl, git2, curl, etc) - я про это уже писал, и повторю еще раз. Код эти пионеры вендорят, данные - нет. Потому что вендорить корневые сертификаты - это сложна, одной системой сборки не обойтись. Поэтому, конечно, найти в системе корневые сертификаты свежеиспеченный cargo не умеет.

https://lwn.net/ml/gcc/CAGWvnym7--36T6L6XhhVhQmafR-w3g1NE1Zh9qTbjcC325Us1Q@mail.gmail.com/

В gcc собираются включить наработки #gccrs, то есть, добавят реализацию Rust.

Это будет уже третья реализация, помимо основной, и #mrustc(https://github.com/thepowersgang/mrustc).

Я надеюсь, они таки сделают процедурные макросы не с помощью загрузки .so(а, например, использовав miri, или что-то подобное), и у меня появится нормальный компилятор Rust.

Ну и факт того, что он написан на С++, не может не радовать, это всегда хорошо для #bootstrap

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608387.html

В gcc вмержили gccrs (rust frontend).

Выглядит это всrustо, потому что я никогда не видел, чтобы такой сырой продукт вмерживали бы в mainline gcc.

Ну, то есть, по мощщи эта поделка пока не дотягивает даже до #mrustc, который в состоянии бутстрепнуть современный компилятор Rust.

gccrs, насколько я понимаю, не умеет даже такого (Я не прав? Поправьте!)

Короче, какое-то странное, наверное, политическое, решение.

https://rust-gcc.github.io/2023/04/24/gccrs-and-gcc13-release.html

Оправдание на тему "почему мы все никак не допилим gccrs до состояния можно попробовать".

На мой взгляд, это все не выдерживает никакой критики, потому что #mrustc.

С musl, и с их чисткой "ненужного" кода, конечно, попандос.

https://github.com/bminor/binutils-gdb/blob/master/gdbserver/linux-low.cc#L5384

Вот, gdb, например, при configure, считает, что pread64 больше нет, потому что смотрит на линкер, а не на компиляцию. И в данном ifdef попадает на fallback, компиляция которого валится каким-то интересным образом.

Или, вот, например, как валится сборка std crate через #mrustc:

ld.lld: error: undefined symbol: open64
>>> referenced by libstd.rlib.c
>>>               .../libstd.rlib.o:

Я так понимаю, что оно так же будет валиться и со сборкой с обычным rust (контора пидорасов, не забываем про это!), потому что коллеги тоже пишут ffi руками, без определения того, что же есть под ногами.

Нормального способа в musl узнать про наличие той или иной фичи нет, и это их принципиальная позиция.

Я пока откатил версию musl к херам.

Будни #bootstrap

Тем временем, я воспроизвел цепочку сборки rustc/cargo 1.54.0 от проекта #mrustc (большое им спасибо и долгих лет жизни) - https://gist.github.com/pg83/b114dc78ce39a41fb8c895580a005dd0

То есть, у меня есть функционирующие cargo и rustc, которые пока не могут собрать сами себя, из-за того, что rustc хочет линковать и подгружать .so.

Если кто-то хотел интересных задач, да и просто погрузить свои шаловливые ручки в #stal/#ix - сейчас самое время!

https://lwn.net/SubscriberLink/954787/41470c731eda02a4/

#gccrs

rust in gcc стагнирует, и далек даже от того состояния, в котором сейчас находится #mrustc. mrustc уже умеет в 1.54, а вот эти вот товарищи пытаются в 1.49, да и то, там конь еще не валялся.

https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=GCC+Rust+Update.pdf

Пролистал слайды про устройство proc macro в gccrs, смерть смерть кладбище, тоска, они собираются точно так же динамически линковать и загружать .so, как это сейчас делает rustc.

А, значит, они мне совершенно бесполезны.

Будни #bootstrap

https://notgull.net/announcing-dozer/

Коллега собирается запилить компилятор Rust на plain c.

Зачем?

Ну, потому что коллега считает задачу #bootstrap важной, но так же он считает, что цепочка C -> C++ -> #mrustc -> Rust - слишком сложная.

Поэтому вот пилит на чистом C.

Ничего у него, конечно, не выйдет, потому что это запретительно дорого (https://t.iss.one/itpgchannel/1279). У него просто не будет нужного количества времени (разве что, к нему не присоединится еще человек 10).

https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust.html

#gccrs, в очередной раз, пытаются объяснить, зачем они нужны, когда есть rustc, #mrustc, и rustc_codegen_gcc.

И, в очередной раз, у них это получается плохо. Потому что они не нужны (не решают существующих задач).

https://github.com/thepowersgang/mrustc #mrustc

Чувак, конечно, монстр.

Сейчас он умеет в #bootstrap 1.74, и это снова очень близкО к trunk.

Респект, уважуха, мы таких безумцев очень любим.

https://www.phoronix.com/news/More-Rust-Merged-GCC-15.1

145 патчей от #gccrs!

В этот раз они решили, что таргетировать будут ажно 1.49 версию.

Напомню, что мою любимый #mrustc https://github.com/thepowersgang/mrustc умеет уже в 1.74, практически, в одно (мотивированное) рыло!

Да, да, я понимаю, что у gccrs задача чуть сложнее - им надо запилить настоящий borrow checker, но, тем не менее, состояние проекта кажется странным.

https://www.phoronix.com/news/Rust-Debian-2025

"around 8% of the source packages in Debian Sid are building against at least one librust-* package. That 8% figure for Debian source packages building against at least one Rust library package is around double of what it is for Debian 12 "Bookworm". Quite a significant uptake over the past few years and it's only continuing to grow with more open-source projects introducing varying levels of Rust integration"

Понятное дело, что это librsvg, или какие-нить кодеки, которые не являются обязательными, но против них нужно собраться, чтобы получить "полный" пакет, но, тем не менее, цифра довольно внушительная.

У меня против Rust собирается ровно 0 от базовой системы, потому что librsvg для загрузки иконок в gtk я переписал на кастомный #svg loader over #lunasvg/#skia/#svgren (по выбору), и убрал все эти опциональные зависимости.

Ну просто потому, что Rust не является #bootstrap абельным (я не могу собрать его из исходников, не имея под рукой готовый компилятор Rust, подробности в моей эпопее с #mrustc), а это зашквар.