25 июля 2026 года разработчик, которого я никогда не встречал, открыл проблему № 362 в моем проекте с открытым исходным кодом SuperCLI. Они запустили сценарий установки. Это не удалось: sc-machin: /lib/x86_64-linux-gnu/libc.so.6: версия `GLIBC_2.38' не найдена Их дистрибутив Linux поставляется...
25 июля 2026 года разработчик, которого я никогда не встречал, открыл проблему № 362 в моем проекте с открытым исходным кодом SuperCLI. Они запустили сценарий установки. Это не удалось:
sc-machin: /lib/x86_64-linux-gnu/libc.so.6: версия `GLIBC_2.38' не найдена
Их дистрибутив Linux поставлял более старую версию glibc. Мои двоичные файлы выпуска были динамически связаны с более новым. Классическая ошибка переносимости — ее легко исправить, если вы знаете причину, но она невидима, пока кто-то из другого дистрибутива не попробует ваш инструмент.
8 августа вопрос был закрыт. Исправление было объединено. Протестировано. Проверено. Отправленный.
Я не трогал это.
Что произошло с 25 июля по 8 августа
Мой парк AutoMaintainer следил за репозиторием SuperCLI. Когда появилась проблема № 362, планировщик обнаружил ее в следующем цикле обслуживания — точно так же, как он обнаруживает любую открытую проблему в поддерживаемом им репозитории.
Вот что сделал агент, шаг за шагом:
Прочитайте проблему — проанализировали ошибку, определили, что GLIBC_2.38 не найден как основная причина.
Ориентирован на кодовую базу — найден рабочий процесс выпуска GitHub Actions, который создает двоичные файлы Linux.
Выявлено исправление — двоичные файлы были динамически связаны; исправление заключалось в статической сборке с помощью musl-gcc
Реализовано изменение — обновлен рабочий процесс установки musl-tools.