Попробовал использовать mold в качестве основого линкера.

#bootstrap_science

Я как-то уже писал, что у меня есть возможность собрать целое поддерево с уникальным набором флагов. Это прямо незаменимый механизм для bootstrap. Потому что весь bootstrap можно выразить как последовательность шагов вида "собрать мешок инструментов версии N с помощью мешка инструментов версии N-1". #bootstrap

Немного в сторону, такой подход позволяет построить полностью автоматизированную цепочку bootstrap - берем мешок инструментов, и начинаем применять эту цепочку. На первом этапе получится собрать только libc, на втором - какие-то инструменты попроще, и так далее.

В случае возникновения затыка смотрим, чего не хватает, докидываем в мешок недостающее, и повторяем процесс.

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

Я еще раз подчеркну - с N-1 набором инструментов автоматически пересобирается все поддерево библиотек. Это на порядки упрощает конструирование цепочки bootstrap. Если бы ее пришлось переделывать на каждое новое добавление в цепочку по типу mold, то мне вручную бы пришлось описывать перестроение целого ряда библиотек. Например, для mold мне бы пришлось руками описывать сборочные файлы для boot-openssl, boot-intel-tbb, boot-xxhash, etc. А так все "само": https://github.com/pg83/mix/blob/main/pkgs/bld/mold/mix.sh#L4 (синтаксис уебищный, я там хочу что-то типа json, но мои задачи пока решает)

Вот это вот std_env= - это и есть указание, что нужно пересобрать все поддерево с определенными инструментами.

К сожалению, mold сыроват. На удивление, он слинковал все пакеты, но вот в одном случае у меня упал configure script вот с такой записью в log:

[15730.052723] conftest[4744]: segfault at 31 
ip 000000000020100b sp 00007ffdf79cae10 
error 6 in conftest[201000+1000]
[15730.052732] Code: 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 50 bf 3c 00 00 00 e8 
45 06 00 00 <00> 48 31 ed 48 89 e7 48 8d 35 
e7 ef df ff 48 83 e4 f0 e8 00 00 00

mold неверно слинковал какой-то тест для configure. Рестарт помог, и это совсем печально - ошибка нестабильна. Впрочем, это неудивительно, mold активно использует треды, и их тайминги - потенциальный источник нестабильности.

Надо понимать, что это очень серьезная проблема, потому что, в итоге, мы получаем систему в которой configure по рандому отключил какие-то фичи.

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

#bootstrap #bootstrap_science

У меня давно стояла задача - научиться прикапывать какое-то подмножество пакетов, чтобы, при очистке сборочного кеша, сборка не начиналась с 0.

Сейчас поясню на пальцах.

Допустим, вы, в процедуре bootstrap, собираете clang + coreutils, которые, потом, используются для сборки всего остального. Но для их сборки вам нужны промежуточные инструменты A, B, C.

Вы собрали себе нужный набор пакетов, сделали #ix gc, после чего A, B, C были удалены, так как они никому не нужны для работы.

А теперь, представьте себе, что какой-то конечный, user visible код случайно по сборке стал напрямую зависеть от A(или от B, или от C) Тогда, при попытке собрать этот таргет, нам придется воссоздать A, а значит, пройти всю цепочку bootstrap целиком.

Собственно, моя задача - найти такое множество пакетов, которе, если "заякорить"(то есть, сделать доступными после ya gc), то bootstrap никогда не будет происходить полностью(кроме как случаев, когда меняется сама цепочка bootstrap).

Я пробовал найти такое множество пакетов пару раз, но оно получалось вкривь и вкось.

До тех пор, пока я не переделал цепочку bootstrap, как в предыдущем посте, на который я ответил.

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

Понятно же, почему это правило порождает необходимый и достаточный набор инструментов?

Потому что если прикопать именно его, то вот этот самый N-1 набор инструментов больше не понадобится, и потому что этого набора заведомо достаточно, чтобы собрать все остальное.

Вот, я перечислил все такие инструменты в 1 таргете - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bld/ix.sh

Это очень удобно, потому что теперь, чтобы прикопать эти инструменты, мне достаточно завести #realm с этим таргетом(realm задает множество корней для gc).

Все, как я люблю - нового механизма не случилось, а его функции исполняются старыми.

Будни #bootstrap, #bootstrap_science

Вчера я рассказал про сборку #qt, конкретно, про:

* набор (неортогональных) флагов, которые чуть по разному решают в qt задачу принудительной сборки бинарников в host-target режиме

* про то, что они написали поверх #cmake свой слой кросс-компиляции

* про то, что их система сборки сравнима с "Войной и Миром" Толстого(как по актуальному размеру, так и по уровню графомании)

Сегодня про то, как оно сломалось при обновлении до qt 6.4, и как я "ловко" и "изящно" это обошел.

Есть такой проект - https://github.com/qt/qtdeclarative, и он жестко отказался собираться после обновления. С ошибками конфигурации где-то в недрах своих cmake хелперов, без внятной диагностики(это, кстати, отдельная боль в cmake).

Выглядело это так, как будто сломались вот эти самые механизмы, про которые я писал ранее - аццкая кросс-компиляция + комбинация флагов для сборки. Неудивительно, потому что вряд ли их тестировали в таком сочетании.

С симптомом круговой зависимости, что, мол, какой-то файл зависит от цели, которой нужен какой-то собранный бинарник(с говорящим названием qmltoolregistrar), который зависит от этого же файла. Скажем, вот тут - https://github.com/qt/qtdeclarative/blob/dev/src/qml/Qt6QmlMacros.cmake#L2494

Я копался в этом часа 3, но починить так и не смог, из-за размеров этой махины.

В итоге дорожку к результату я "протоптал" так - если там нет актуальной круговой зависимости, и она только в шизанутой системе сборки от qt, то давайте ее "разорвем" - соберем проект по частям.

Как это было сделано?

* Удаляем из сборочных файлов круговую зависимость. https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L13 После этого получается битый makefile, но его достаточно, чтобы осуществить первые этапы сборки.

* https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L4 - собираем все, что собирается этим битым makefile, и устанавливаем в качестве сборочного результата

* Повторяем эти шаги, постепенно увеличивая число собирающихся таргетов, и используя предыдущие результаты как host тулзы - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/2/ix.sh#L14

Мне понадобилось 2 шага - https://github.com/pg83/ix/tree/main/pkgs/bld/qt/6/tools/qml, результат второго шага вполне достаточен, чтобы им собрать полноценный пакет - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/ix.sh#L12.

Я не рассказал про всякие мелочи, типа ручного релоцирования из build в output директории получившихся cmake файлов, чтобы дальнейшие шаги сборки могли их подхватить - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L21

Звучит это все довольно страшно, но сборку эти 2 дополнительные стадии почти не замедлили, потому что в них собирается процентов 5 от всего набора исходников этого пакета.