LINUX.ORG.RU
Форум — Development  

Кто как быдлопакеты собирает?

 , , , ,


0

1

Вот написал я свою трёхмерную ерунду, сишка без ничего линух-специфичного, попенгл, GLFW из репы убунты, math, phtread, stb_image из репы. Динамический бинарник 300 кб. Как теперь мучать широкую аудиторию этой какашкой? Гурии советуют собирать GLFW из сорцов с DBUILD_SHARED_LIBS=OFF, получится статическая либа с которой если собраться - будет статический конечный продукт. Это точно всё? А остальное? А может попроще как-то можно, кинуть libglfw.so в папку к бинарнику и готово?

← Установка пакета с параметрами
Не инициализируется platform driver под Armbian →

Никак? Пусть собирают из исходников. Только сделай по-нормальному, не через быдло-мейкфайлы. Через тот же Meson, например.

anonymous
()

будет статический конечный продукт.

Я тоже считаю что собирать надо статически кроме ну совсем уж общеупотребительных библиотек типа libc например. Динамическая линковка была актуальна в те времена когда приходилось экономить место на дисках. Сейчас она создает больше проблем чем приносит пользы.

watchcat382 ★
()
Ответ на: комментарий от watchcat382

Насчёт сборки софта без GUI или имеющего GUI через веб-морду:

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

А текущая архитектура glibc это звиздец.

Хотя если собирать так, чтобы линковаться к glibc динамически, а остальное линковать статически - то норм, жить можно.

Насчёт сборки софта с GUI - тут нет адекватных решений, приходится линковаться к динамическому зоопарку.

wandrien ★★★
()
Ответ на: комментарий от wandrien

Насчёт сборки софта с GUI - тут нет адекватных решений

Почему вдруг нет? Да,если собирать статически то будет большой размер бинарника. Но сейчас это никого не беспокоит. Что мешает прилинковать например вот эту GUI библиотеку: https://github.com/Immediate-Mode-UI/Nuklear А вот эту даже я сам лично статически линковал: http://xforms-toolkit.org

watchcat382 ★
()

ничего линух-специфичного
Как теперь мучать широкую аудиторию этой какашкой?

Пакуй в MyAwesomeSetup.exe, а линуксойды могут и из сорцов собрать. А если не могут – значит оно им особо и не нужно.

anonymous
()

Ты самое важное не указал, исходники будут открыты?

Если нет, то лучше монолит с единственной зависимостью от glibc скомпилить.

Если да, то как справедливо заметили можно оставить это на откуп пользователям (хотя пользователи нынче не те, так трехмерная ерунда в широкую аудиторию не попадет).

Промежуточный вариант - собрать deb и rpm, там прописать зависимость от дистрибутивного glfw. Либо упаковать в tar.gz и в файлике INSTALL указать что надо поставить.

С флатпаками и прочей нечистью не связывайся - для тридэ там вагон проблем, а уж если оно ещё и со звуком…

eagleivg ★★★★★
()

замонстрячь реальный open-source: пакуй сорцы вместе с tcc :-) компиляция/сборка на месте при первом обращении.

Сдаётся что и по размеру будет меньше чем flatpack/appimage и сильно портабельнее (можно положить tcc для linux/win/macos)

MKuznetsov ★★★★★
()

В большинстве случаев разработчики прикладного софта действуют так:

  1. Исходный код в tar.что-то или на GitHub/GitLab/Bitbucket
  2. Собранный в Ubuntu LTS 20.04 или Ubuntu LTS 22.04 бинарь и все его ресурсы нужные для работы запакованные в tar.что-то без зависимостей в виде любых SO библиотек кроме своих собственных и/или малопопулярных. Те кому нужна программа в архиве сами всё установят себе в дистрибутив.
  3. Flatpak
  4. DEB-пакет для Ubuntu/Debian по вкусу ибо процесс дебилизации дебианизации программы и размазывания её по убогому юниксовому FHS не из приятных.

AppImage и Snap лучше обходить стороной. RPM ввиду малой популярности и плохой десктопоориентированности тоже.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)

Не трать силы, потратишь кучу времени на бинарник который будет работать на 10% систем, остальные будут слать тебе issue про очередной GLIBC_VERSION на которые придётся тратить ещё кучу времени.

Выкладывай исходники, всё. Главное - нормальная система сборки (CMake).

anonymous
()
Ответ на: комментарий от anonymous

Если уж за upx браться то сначала strip-ом все отладочные символы убирать, потом upx-ом дожимать. Только зачем оно? У троянцев разве что смысл есть и у lazarus-а и их компилятора паскаля, который за собой дерьмо не чистит.

peregrine ★★★★★
()
Ответ на: комментарий от watchcat382

Сейчас она создает больше проблем чем приносит пользы.

Имаджинируй уязвимость в openssl. Обновили shared либу, и вот все прекрасно. А полюзыватели род-linux переустанавливают всю систему с почти с нуля.

kawaii_neko ★★★★
()

Если ты любишь своего пользователя, то делай Flatpak или Snap. Snap попроще сделать, так как можно просто перепаковать локальный deb пакет. С Flatpak нужно быть готовым самому компилировать свои зависимости

ifc731
()
Ответ на: комментарий от ifc731

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

anonymous
()
Ответ на: комментарий от EXL

Озвучу противоположное мнение:

AppImage — это единственный нормальный способ поставки бинарника с кучей зависимостей, который нахожу приемлемым. Ничего восхитительного в таком подходе нет, просто меньшее из зол.

А вот Snap и Flatpak почитаю концептуально омерзительными и категорически не связываюсь.

anonymous
()

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

Qui-Gon ★★★★★
()
← Установка пакета с параметрами
Development
Не инициализируется platform driver под Armbian →