>[оверквотинг удален]
>>>с autotools на предмет их собираемости на OpenBSD с использованием bsd-utils?
>>>Что делать авторам программ, которые не собираются на OpenBSD с использованием
>>>bsd-utils?
>>
>>Если б дело ограничивалось только GNU utils… Да, и вас не смущает
>>наличие двух идентичных утилит в системе? В два раза больше уязвимостей,
>>в четыре раза больше проблем — вы это предлагаете?
>
>А вы собираете пакеты на боевых серверах, да еще и рутом? Тогда
>мы идем к вам! На прошлом месте работы приходилось, специфика отрасли. Впрочем, я-то уязвимостей не боюсь, слежу худо-бедно, а вот клиенты…
>>Если программа хочет, скажем, поддержку какой-то функции, а autotools не может найти
>>нужный заголовочный файл, кто виноват, м?
>
>Autotools не выдвигает требований к среде исполнения программы, которая получается в итоге
>сборки, а только к среде сборки, если мне не изменяет склероз,
>в xBSD доступен chroot(1), где можно поставить любые, даже самые экстравагантные
>сборочные зависомости, и получив бинарник, все это г... удалить
Можно. Осталось только всё это говно поставить. И убедиться, что проблем не возникло. Хорошо, если у вас восемь ядер и четыре гигабайта — а если это MIPS?
Опять же, ладно зависимости — в портах они легко указываются и далее всё (теоретически) автоматом ставится… а вот хрен. То configure не может что-то найти (потому что ищет только в /usr/lib , например). То всплывает какой-то ключик компилятора, доступный только в новейшей версии. То ещё подобная хрень. Хуже того: нередко появляются зависимости, которые в configure не видны, и выясняются, в лучшем случае, только при (к счастью, в OpenBSD такое есть) автоматизированной проверке на тему используемых библиотек.
Я не раз сталкивался, например, с тем, что configure говорит: «парень, а у тебя компилятор-то не умеет создавать разделяемые библиотеки!». И ковыряешься, ищешь ошибку, и в итоге выясняется, что тест цепляет какой-то левый заголовок и вполне резонно обламывается.
