Прибитые к ./configure --prefix=/usr программы...

Почему куча остальных программ написана через задницу?

По той же причине, по которой боги сишки плодят дыры use-after-free.

Причина такая: на словах все Львы Толстые, а на деле - …

Тут проблема-то получается не техническая, а культуры, то есть того, «как принято у других». «Если все вокруг херачат захадкоженные константы, ну значит и я буду, наверное это правильно.»

Если бы разрабы бы того же gcc или libiberty хотя бы как-то пиарили такой подход к разработке: писали бы маны, заметки в инете, учебные материалы и т.п.

А то я вот, например, реально только сегодня узнал, что gcc умеет сам искать свои пути.

Потому что у большинства и так работает. И попытки донести мысль что это не правильно ни к чему не приводят.

Ну строго говоря, у тебя там не полностью корректный способ. Более лучше использовать вот эту make_relative_prefix() из сабжа, ну или её велосипедный аналог. (У меня в коде свой велосипед, похожий по смыслу.)

Ну а так да, по ссылке типичный пример «сделано по тупорылому туториалу с хардкодами путей».

Почему куча остальных программ написана через задницу?

Чтобы нам жизнь мёдом не казалась.

Потому что программисты – петухи.

Я не умею хорошо объяснять, поэтому показал общий принцип.

Особенно программисты Java, обмазавшиеся maven и XML))

Я и не отрицаю. Старый петух лучше новых двух.

Почему куча остальных программ написана через задницу?

Ну я так понимаю что ты имеешь в виду чтобы программа сначала искала файлы по prefix, а если не найдёт то искала в своём pwd?

Почему всё типичное, что может прочитать an average developer о сборке ПО для линукс - это то, как захардкодить

Потому что захардкожены пути в дистрибутивах для бинарей,библиотек,документации и прочего прочего прочего. И у всех всё почти одинаково, но чуть по разному и это разное и прописывают в prefix так как нет никакого Program Files где каталог с программой и внутри всё что ей нужно. Даже библиотеки не подхватываются лежащие рядом с исполняемым файлом надо LD_LIBRARY_PATH/LD_PRELOAD прописывать. Но это не к программам вопрос уже, хотя и они могут рядом с собой искать библиотеки и если есть через dlopen грузить их. Но это уже чёто…

Вот твоя программа какаянить фиг с ними с библиотеками, а конфигурационные файлы ещёт сначала в своём pwd потом в /home/$USER/.config потом в /etc/app/app.conf.d/app.conf затем в /etc/app/app.conf? Сомневаюсь, максимум в паре мест и всё. Вот и другие не парятся :D

ИМХО

Стиль «базар», Линус одобряэ.

Вот твоя программа какаянить

https://sde-gui.github.io/libsde-utils/

Петухи - их руководство и да, те которые считают PHP, Python и Ruby ЯП.

Ну, норм. =)

А так я за --prefix и на уровне сборки программы, ну просто потому что надо конпелять например для linux/bsd/android termux/dreamcast/иное, везде свои приколы и надо настраивать на этапе сборки ресурсы (редактируемые например) порой просто невозможно хранить рядом с исполняемым файлом. Плюс на уровне ключа запуска программы --prefix, пусть она хоть chroot в указанный префикс делает и всё, уже норм.

Ну вот например твою библиотеку использовать, программа всё же ожидает в любом случае свои файлы расположенные в определённой структуре каталогов, всё что надо это либо задать ей вариативность префикса этих каталогов и на этапе сборки и добавить к программе ключ тот же --prefix=где_аппшкины_файлы_лежат и всё и норм.

А куда деваться то. Хочешь в дистрибутивы размазывай свою программу по всему FHS который у всех разный, был бы одинаковый никаких prefix и не нужно было бы, либо собирай в статику всё, либо ещё чёнить. А так в 99% случаев программе достаточно просто сделать chroot в каталог с ресурсами лежащими не относительно / и всё будет работать. Но что-бы над тобой не смеялись размазывай по FHS. Исключение игрушки, там изкоропки у всех можно поменять местоположение всего и вся, ведь это серьёзное ПО безотказно работающее десятилетиями на разных ОС без пересборки, которое вообще не надеется на ОС кроме базовых вещей. :D

FHS тут вообще перпендикулярно.

FHS явно придумали какие-то чуваки с ОКР, иного объяснения этой чудной спеке я не вижу. И из-за них теперь весь мир страдает.

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

Допустим твоя утилита хочет получать шрифты, не свои, а системные, куда она полезет будучи собранной под линуксы? В её pwd каталоге их не будет, полезет она туда сам знаешь куда, а это куда может плавать от дистрибутива к дистрибутиву и либо ты на этапе сборки определяешь где что, либо в своём ПО все эти варианты прописываешь и при работе оно в рантайме пробует взять откуда получится =)

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

FHS определяет дефолты, а не заставляет прибивать к ним программы.

Удивительно, в 2023-м году приходится объяснять линуксоидам, что бывают системные ресурсы, а бывают - ресурсы приложения.

Вот бы система могла так: программа ей «мне нужны шрифты», система ей «на тебе шрифты», программа ей «мне нужна такая-то либа», система ей «на тебе эту либу».

А где это всё лежит в системе и в каком виде - не имеет значения.

система ей «на тебе шрифты»

man fc-list

Ну, либо так, либо Program Files. Ну есть ещё упоротый uuid метод в nixos что по сути тот же Program Files только с не читаемыми каталогами :D Нормального ничего нету, идеал где то между ними всеми взятыми.

А так три режима работы программы, «всё своё ношу с собой», «всё что мне надо лежит вон там»,«всё что мне надо лежит вон там, но если есть возьму вот тут» решает все проблемы ИМХО, только работать это должно прозрачно для программы. Хотяяя если бинарю можно подкинуть левую библиотеку по его относительному пути и оно его молчком подгрузит то это тоже такое себе. Ой ладно. Чайку над попить, утомили томные беседы

Нормального ничего нету

https://www.gobolinux.org/

https://www.dragora.org/en/index.html

Чайку над попить, утомили томные беседы

Сам себя запутал, наворотил с три короба.

На самом деле достаточно таскать с собой манифест ресурсов, где указывать их местонахождение. И тогда будет насрать где фактически они лежат.

Наверно потому что gcc часто по несколько версий в системе, включая кросскомпиляторы, и их надо размещать в разных местах

Почему куча остальных программ написана через задницу?

Это каких? У большинства всего один бинарник и его можно класть куда угодно.

лучше использовать вот эту make_relative_prefix() из сабжа, ну или её велосипедный аналог

Заинтересовался, загуглил. 430 строк! Да вы с ума сошли?!

Но идея толковая, особливо в «не полностью корректном» зато тривиальном изложении DrBrown, учту, сенькс.

Почему использование make_relative_prefix() или её аналога не входит в best practices и не описывает в туториалах по сборке программ под линукс?

Потому что недостаточна массовая поддержка в библиотеках/системах сборки?

Потому что недостаточна массовая поддержка в библиотеках/системах сборки?

А почему она недостаточная?

А почему она недостаточная?

[nostalgia] Потому что фича дюже важная, вестимо.

Автолулзы говно, а все кто их пихает должны быть кастрированы без наркоза.

То есть собираем gcc, например, с ./configure –prefix=/fake-usr, а потом копируем установочный каталог в любое место хомяка и без проблем пользуемся.

А это было там изначально или же недавнее нововведение? У меня есть пара тулчейнов для старых девайсов на основе GCC 3.3 и GCC 3.4.3 и там компилятор именно что требует тот путь, который был указан в prefix и при переносе нужно будет делать симлинк.

В GCC 3.4.6 это точно есть, у меня он собранный лежит.

Кроме автодетекта, там есть еще опция -B и переменная окружения GCC_EXEC_PREFIX.