Будни #bootstrap

У меня тут с переходом на libc++16 (из llvm16) сломалась сборка imhex, с довольно странным сообщением:

...iteration_proxy.hpp:18:14: 
    fatal error: 
    'ranges' file not found
    #include <ranges> // enable_borrowed_range

Случилось это по забавной причине. Библиотека nlohmann-json определяет поддержку рейнджей примерно вот таким образом:

#ifndef JSON_HAS_RANGES
    // ranges header shipping in GCC 11.1.0 
    // (released 2021-04-27) has syntax error
    #if defined(GLIBCXX) && GLIBCXX == 20210427
        #define JSON_HAS_RANGES 0
    #elif defined(__cpp_lib_ranges)
        #define JSON_HAS_RANGES 1
    #else
        #define JSON_HAS_RANGES 0
    #endif
#endif

Тут, в целом, написано, что мы доверяем стандарту, посредством define __cpp_lib_ranges, который оставлен на откуп стандартной библиотеке.

libc++16 считают, что у них появилась работающая поддержка ranges, а я с ними не согласен, потому что они упыри (пилят свою собственную реализацию, вместо того, чтобы взять каноническую range-v3)

Поэтому я удаляю их огрызок, а всем клиентам делаю зависимость на v3. https://github.com/pg83/ix/blob/main/pkgs/lib/c%2B%2B/14/ix.sh#L92

Ну и тут получилось так, что nlohmann-json собралась успешно, потому что зачем проверять компиляцию поставляемых заголовков, а клиент - сломался, потому что у него закономерно нет зависимости от range-v3.

Я добавил зависимость https://github.com/pg83/ix/blob/main/pkgs/lib/json/nlohmann/11/ix.sh#L9, и дописал тест, проверяющий, что поставляемый файл конпелируется https://github.com/pg83/ix/blob/main/pkgs/lib/json/nlohmann/11/ix.sh#L21

(А еще libc++16 удалили std::binary_function. Я тут отдельно хочу #rant, что создателям c++ надо было сделать std2, std3, и так далее, но не портить std, который std1)

Мораль? Ее нет. Жизнь - боль.

#llvm

Я несколько раз рассказывал, что бинари в тулчейне от llvm - не совсем бинари, а ссылки на основной бинарь, который, по значению argv[0], делает диспетчеризацию в нужную функцию. Так работает busybox, это один из важных способов сэкономить на размере бинаря в случае статической сборки.

Например, llvm-strip - это символическая ссылка на llvm-objcopy.

Я тут задался вопросом, будет ли работать символическая ссылка "strip" -> "llvm-objcopy".

Понятно, что оно может работать, а может и не работать, смотря как сделать диспатчинг по argv[0].

Вот как оно сделано в llvm - https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-objcopy/llvm-objcopy.cpp#L319

bool IsStrip = sys::path::stem(ToolName)
    .contains("strip");

Сделано оно очень хорошо и правильно, "широкими мазками", без попытки выпилить лобзиком только "llvm-strip".

Это очень грамотное решение, оно позволяет одним и тем же бинарем заменить:

strip
linux-gnu-x86_64-strip
...
llvm-strip

И так далее.

По сути, покрывает все возможные вызовы strip, в кросс-компиляции, для замены в gnu toolchain, etc.

LLVM, в очередной раз, порадовали.

https://utcc.utoronto.ca/~cks/space/blog/programming/Go121LinuxStaticToolchain

Пишут, что, начиная с go 1.21, по умолчанию бинари самого go будут статически слинкованы.

Собственно, причина, почему это было не так - резолвер в glibc. И дело не в том, что резолвер из glibc нельзя влинковать к себе статически (сложно, но можно), а проблема в /etc/resolv.conf, который в glibc не специфицирован, и разные версии glibc могут себя вести немного по другому с одним и тем же конфигом.

Интересно, как инженеры Гугла обошли эту проблему? Поддержали все изыски glibc resolver в своем pure go resolver?

Или просто решили, что небольшой процент пользователей, решивших использовать синтаксис resolv.conf на полную катушку, может чутка пострадать? В целом, норм, им все равно не привыкать.

Я так-то считаю, что sane resolv.conf должен содержать в себе всего одну строку:

pg# cat /etc/resolv.conf 
nameserver 127.0.0.1

А дальше вы настраиваете локальный кеширующий резолвер, конфиг которого будет полностью независим от libc.

Продолжаю регулярно (чисто из спортивного интереса, оно пока неюзабельно) собирать #hyprland.

Иногда, конечно, бывают такие ошибки сборки, что хочется сеть, заплакать, и никогда больше не собирать код на C/C++:

.../range/v3/algorithm/
    partial_sort_copy.hpp:
    46:27:error: expected a 
    qualified name after
    'typename'
    typename PI = identity,

../src/src/layout/../defines.hpp
    :92:12: note: expanded 
    from macro 'PI'
#define PI 3.14159265358979
           ^
In file included from 
    ../src/src/layout/
    MasterLayout.cpp:3:

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

Поборол я сборку #hyprland, в целом, сейчас оно может служить такой альтернативой sway, для любителей свистелок и перделок. Sway, но с красивой и плавной анимацией, и переходами. Мне не понравилось.

Обнаружил, что свежий hypr стал зависеть от udis86: https://github.com/hyprwm/Hyprland/blob/main/meson.build#L48

Слушайте, вот где window manager/compositor, и где встраиваемый дизассемблер?

Вот, полюбуйтесь: https://github.com/hyprwm/Hyprland/blob/main/src/plugins/HookSystem.cpp#L67

Что тут происходит? А хер его знает, что тут происходит, наверное, что-то плохое. На лету модифицируют загружаемые плагины.

Следить оно за тобой будет, %username%, и отсылать данные "куда надо"!

#llvm, будни #bootstrap

Сегодня llvm не молодцы.

В libc++16 появился заголовочный файл libunwind.h. Но есть один нюанс - уже есть библиотека, в котором тоже есть libunwind.h:

pg# ls /ix/store/F...6-lib-unwind/include/ 
    | grep libunwind.h
libunwind.h
pg# ls /ix/store/i...m-lib-c-plus-plus-16/include/ 
    | grep libunwind.h
libunwind.h

Теперь успех сборки какого-то софта зависит от порядка перечисления этих библиотек в зависимостях.

Дело еще осложнилось тем, что у меня, по сути, почти все зависит от libc++, потому что я всякие свои дополнения для musl (например, кастомный dlopen) пишу на С++, а на чем же еще? Пришлось повыпиливать лобзиком.

Ссылок не даю, там нет ничего (технически) интересного, так, жонглирование зависимостями.

Закрывая (кажется) тему #llvm libc++16 на ближайшее время.

В libc++ есть своя реализация format (почему? потому что могут же!), но она не работает. Поэтому авторы ее закомментили, до поры, до времени - https://github.com/llvm/llvm-project/blob/main/libcxx/include/format#L176

Но вот в последнем релизе libc++ эта реализация вылезла наружу, без каких-то guard на использование, через заголовочный файл vector - https://github.com/llvm/llvm-project/blob/main/libcxx/include/vector#L295

Что, ожидаемо, ломает проекты со своими polyfill (во какое слово узнал!) https://gitlab.com/ananicy-cpp/stl-polyfills/std-format/-/blob/main/polyfills/format/format

Ломает понятным образом - в namespace std:: появляются 2 реализации std::format.

#rant open source такой open source - тестов нет, все сломано, ничего не работает, и работать не будет.

https://lists.freedesktop.org/archives/xorg-devel/2023-March/059004.html

Нам пишут, что никто не хочет руководить проектом Xorg - не нашлось достаточного количества номинантов, чтобы начать выборы.

Меня тут, конечно, гораздо больше заинтересовал список текущих директоров - "The directors who received two year terms starting in 2022 were Emma Anholt, Mark Filion, Alyssa Rosenzweig and Ricardo Garcia"

Вот вы говорите, что в IT мало женщин. Ну как же мало, если 2 из 4 позиций директоров xorg - это женщины?

Когда проект, по сути, завершен, и программисту в нем нечего делать, он начинает вылизывать в проекте что-нибудь. #ball_lick

Вот, есть такая сборочная система - #meson. Она, по сути, написана. Там есть все, что может пожелать любой sane сборочный скрипт, и даже много чего лишнего.

Но проект же должен развиваться, нужно катить новые релизы.

https://mesonbuild.com/Release-notes-for-1-1-0.html

Давайте я просто оставлю несколько цитат, про то, какие же проблемы решает проект в своем развитии:

"sudo meson install now drops privileges when rebuilding targets"

Нет, это не помощь пользователю, это очередная боль мейнтейнера, который будет вынужден помнить про очередную неочевидную "магию".

Инструменты должны быть простыми, и должны fail fast, вместо того, чтобы "решить проблему любым доступным образом". Потому что "следующий какой-то доступный способ" сделает чуть-чуть иначе, чем основной.

"meson install now supports user-preferred root elevation tools
Previously, when installing a project, if any files could not be installed due to insufficient permissions the install process was automatically re-run using polkit. Now it prompts to ask whether that is desirable, and checks for CLI-based tools such as sudo or opendoas or $MESON_ROOT_CMD, first"

Вы понимаете, сколько в этом говне прикопано "магии", которая, в зависимости от доступного окружения, будет делать разные действия при выполнении одних и тех же команд? Моб твою ять, поведение сборочной системы зависит от того, есть на машине polkit, или нет.

Ну а еще, конечно, любой "promtps" в batch cli по сборке и установке - это харам.

Я бы с радостью заморозил сейчас версию meson у себя, но ведь всегда найдется какой-нить красноглазый студент, решивший заюзать новую клевую фичу именно в своем сборочном файле.

https://awesomekling.substack.com/p/how-were-building-a-browser-when

Тут вот автор https://serenityos.org/ решил похвастаться историей успеха про то, как они запилили еще один браузер. Не в смысле еще одну обертку над webkit/chrome/firefox, а реально +1 full reimplementation, включая движок JS. #ladybird

except it is not.

https://github.com/pg83/ix/blob/main/pkgs/bin/ladybird/ix.sh - у меня уже достаточно давно умеет собираться снепшот их кодовой базы, к сожалению, пока их браузер не умеет вообще ничего (у меня он валился на простой скачке контента).

Возможно, потому что им приходится велосипедить вообще все (посмотрите на список зависимостей - только QT), потому что основной их потребитель - это SerenityOS.

Пока нет, но очень хотелось бы. Сформулирую так - хотелось бы появления какой-то субкультуры "suckless web", который бы работал в простом браузере, без всех современных изысков в js/html.

Современный веб бесит своей сложностью и монструозностью.

#conan

Как говорится, не выдержала душа поэта, и, вместо пустышки + ручной подготовки структуры директорий по conanfile.txt, я запилил скрипт, который, по conanfile.txt, берет все нужное из окружения, и строит нужную структуру директорий.

Скрипт достаточно хорош, чтобы корректно обработать простой conanfile - https://github.com/ytsaurus/ytsaurus/blob/main/conanfile.txt, и, далее, кореектно собрать YT.

https://github.com/pg83/ix/blob/main/pkgs/bld/conan/conan.py

Натурально, добавляешь ЭТО в PATH, и cmake отрабатывает верно.

https://en.liujiacai.net/2023/04/13/zig-build-system/

Тут вот рассказывают про сборочную систему Zig, zig build.

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

Zig - очень низкоуровневый язык, сборочные файлы "zig build" - тихий ужас.

Ну и, "для того, чтобы собрать программу для zig, нужно собрать программу на zig", тоже очень доставляет.

#rust

https://www.opennet.ru/opennews/art.shtml?num=58969

Слуште, я вот даже не знаю, что сказать по поводу этих новостей.

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

https://github.com/thepowersgang/mrustc/issues/301

Да, да, я знал, куда полезть за жареным. mrustc, кажется (IANAL), вполне себе нарушает новые правила использования торговой марки - "Generally no - it is not permitted to use the Rust name or Logo as part of your own trademark, service mark, domain name, company name, trade name, product name or service name"

Кстати, кажется, я теперь должен писать вот такой вот шебанг в каждый текст про раст?

"проект Rust и организация Rust Foundation не вовлечены в создание и рецензирование содержимого"

Rust Foundation - контора пидорасов!

https://www.phoronix.com/news/Wine-8.6-Released

#wine решили забандлить libm из #musl.

Это, конечно, хорошая тема. Потому что позволяет wine runtime еще меньше зависеть от системы.

Если не можешь статически собрать весь код - то собери статически (ну или, хотя бы, по жестким версиям исходников динамически) свой runtime.

https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats

#fsf высказались по теме выключения поддержки #jpeg_xl в Chromium.

Слушайте, я не смог прочесть этот текст.

У меня опять сработала регулярка на тему "проклятых sjw", на фразе "... issue in the history of the Chromium project, the nominally free basis for the Google Chrome browser"

Мерзотные, левацкие sjw, вот кто такие эти fsf.

Ну вот реально, вот как им еще сказать "вы, конечно, выполняете все правила free software, и мы, конечно, по нашим же правилам, так и должны вас назвать, но вы нам не нравитесь, поэтому вот вам плашка nominally".

Всем же понятно, что есть free software, а есть какое надо free software, и не надо их смешивать!

Или, может, с Mozilla Foundation проще договориться, чем с google? (хер там)

#abi #dwarf #elf #unwind #gold

Я как-то кидал ссылку на реализацию базовых функций Itanium ABI, для раскрутки стека и исключений. Вот, в каком-то смысле, продолжение - а что же там такое делает компилятор с линкером на пару, чтобы поддержать itanium runtime?

https://lesenechal.fr/en/linux/unwinding-the-stack-the-hard-way

Текст - огонь. Он явно войдет в мою золотую коллекцию ссылок про низкоуровневое устройство современных runtime.

По многим темам в интернетах не хватает ссылок уровня upper intermediate - это когда ты еще не прочел 10 стандартов по 1000 страниц каждый, но, после прочтения подходящего текста, ты уже можешь взять в руки какой-то инструментарий, и сделать что-то содержательное.

Есть куча зумерских восторгов вида "гля я заменил __cxa_throw, у меня программа теперь падает новым интересным образом", есть спецификации на ELF/DWARF, которые ни один нормальный человек читать не захочет (если он не на зарплате, конечно), а вот текстов "посредине" - очень и очень мало.

В тексте очень сжато расписано, как устроены разные секции, нужные для обработки исключений, начиная от ELF формата выполняемых файлов, и кончая описанием байткода DWARF, нужного для вычисления значения регистров в разные моменты выполнения программы (в том числе, base pointer), по текущему контексту.

Прямо очень, очень хорошо.

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

#unbound #musl #dns #dnsmasq

Перешел с unbound на dnsmasq, по советам коллег.

(да, я понимаю, что это продукты несколько разных масштабов, потому что unbound - настоящий рекурсивный dns resolver, а dnsmasq - "просто" кеширующая прокся (+dhcp +говна самовар), я их использовал для одного и того же)

pg# ls -la /ix/.../bin/unbound 
... 5683992 unbound
pg# ls -al /ix/.../bin/dnsmasq
... 2948464 dnsmasq

dnsmasq (вроде) не виснет, и весит меньше.

Заодно сделал использование локального кешера обязательным, потому что musl без этого так себе работает - https://wiki.musl-libc.org/functional-differences-from-glibc.html#Name-Resolver/DNS, а люди потом жалуются на alpine - https://martinheinz.dev/blog/92

Коллеги посоветовали посмотреть в сторону #systemd-resolvd, но, КМК, они так шутят, потому что, будучи статически слинкованным, он будет под сотню мегабайт весить, наверное.