LINUX.ORG.RU

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

 , ,


0

1

Хочу собрать приложение на Qt5 которое бы работало на разных дистрибутивах без перекомпиляции.
Взять и скомпилировать все статически не могу ибо LGPL.
Оставлять все динамически слинкованными не вариант, тут даже не факт что возможно будет последние версии Qt5 собрать под Ubuntu 16.04, а возможность запускать софт там нужна.
Думаю попытаться собрать Qt5 динамически но с статически слинкованными библиотеками какими только смогу. Но из-за особенности структуры Qt5 делится на десятки библиотек и при таком подходе будет куча копий одной и той-же библиотеки в каждой Qt5 либе.
Тут я вижу возможные решения:

  1. Все нужные библиотеки пересобрать так чтоб они не зависели от системных, только друг от друга. Боюсь даже думать об этом, не вариант для меня.
  2. Слинковать все статические библиотеки в одну динамическую и уже её линковать динамически для каждой Qt5 либы. Проблема в том что я не знаю как это правильно сделать, если это вообще возможно.
  3. Скомпилировать Qt5 в одну мега-библиотеку и статически к ней слинковать всё остальное. Не верю в то что такое можно легко сделать, если вообще возможно.
  4. Скомпилировать Qt5 статически, но использую метод из п.2 собрать её в одну динамическую и слинковать всё остальное статически к ней.
  5. Забить на это так как наступила эра гигабайтных приложений.

Варианты AppImage, Flatpak, Snappy и остальное такое не предлагать.

★★

Ответ на: комментарий от RazrFalcon

Просто соберите свою прогу с официально собранным Qt и всё.

Теперь бесплатно только исходники, бинари даже GPL/LGPL за деньги.

Для надежности можно на старой убунте собрать.

Были проблемы что прога собранная на 16.04 не правильно работала на 18.04. Пришлось делать отдельные сборки под каждую версию. А как только дистр обновится так сразу вылезут еще проблемы. Проще проблемы на корню рубить.

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

Забить на это, так как надо нормально опакечивать, а не фигнёй страдать.

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

V1KT0P ★★ ()

Взять и скомпилировать все статически не могу ибо LGPL.

А подробнее? Ты проприетарь пишешь? Даже в этом случае ты можешь её соблюсти, предоставив получателям твоего продукта объектные модули.

С опенсорсом же вообще проблем нет, даже если у тебя не GPL/LGPL. Главное, чтобы получатель смог собрать твой продукт с другой версией Qt.

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

А подробнее? Ты проприетарь пишешь?

Да.

Даже в этом случае ты можешь её соблюсти, предоставив получателям твоего продукта объектные модули.

Сомневаюсь что мне разрешат статически слинковать LGPL, особенно если можно обойтись динамической даже путем большего размера бинарей. Ибо место под бинари это забота пользователей, а линковка LGPL это забота юристов.

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

Cmake и conan могут тебе помочь?

Пакетные менеджеры не подойдут. В каждый установочный бинарь/скрипт вшивается конфиг для каждого отдельного пользователя. Ибо указать параметры перед установкой это для пользователя слишком сложно, приходится выкручиваться.

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

А в чём проблема все нужные либы собрать в tar.xz и распаковывать всё разом в /opt?

Это п.1, правда без пересборки библиотек а только с исправлением путей. Наверно если не будет других вариантов то попробую так сделать, ибо увеличение размера директории приложения меня не радует.

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

Так статическая сборка даст тот же объём, разве что одним файлом, а не кучей.

То есть либо использовать системные либы (возможно сделав между системным Qt и приложением некую прослойку, которая будет разная для каждой версии Qt, но иметь идентичный API). Либо таскать Qt за собой. Вроде других вариантов быть не может.

monk ★★★★★ ()

Я бы делал так:

  1. Собрал на ubuntu 16.04 qt и необходимые либы
  2. Создал deb пакет mylibs_v_001.deb
  3. Собрал приложение с этими либами
  4. Создал deb пакет myapp_v_001.deb Пользователь ставит либы и приложение При необходимости обновляет приложение и реже либы

Шаги 1,2,3,4 повторил для rpm дистров на основе fedora примерно ubuntu 16.04

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

Так статическая сборка даст тот же объём, разве что одним файлом, а не кучей.

В статической сборке можно выкинуть часть кода который не используется.
Я пытался искать какие библиотеки нежелательно копировать в директорию программы а оставить зависимость от системного пути но что-то не нахожу. Ибо просто скопировав есть вероятность получить какой-то баг. Например стоит ли копировать ld-linux-x86-64.so.2 или оставить зависимостью от системной.

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

Собрал на ubuntu 16.04 qt и необходимые либы

После того как собранное приложение на 16.04 затем некорректно работает на 18.04 мы перешли на отдельные сборки под 16.04 и 18.04. И я хочу вообще отвязаться от версии дистрибутива или вообще дистрибутива. Постоянно случается что пользователи ставят версию 16.04 на 18.04 и наоборот.

Создал deb пакет mylibs_v_001.deb

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

V1KT0P ★★ ()

Хочу собрать приложение на Qt5 которое бы работало на разных дистрибутивах без перекомпиляции.

Задача в общем случае нерешаема, т.к. например в одном дистрибутиве может быть одна версия ядра Linux, в другом - другая, а библиотека glibc совместима определенными версиями ядра, со слишком старыми или слишком новыми может не работать, и если ты поставляешь у себя вместе с программой саму glibc, то твоя поставляемая glibc может быть несовместимой с тем ядром, которое стоит в системе, и ничего работать не будет. См. https://unix.stackexchange.com/a/430462

SZT ★★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от V1KT0P

Для коммерческого распространения пакетные менеджеры не совсем подходят.

Они подходят для всего.

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

mylibs_stable_v1.0.0.deb ставятся в /opt/mylib/stable

myapp_stable_v1.0.0.deb ставятся в /opt/myapp/stable

mylibs_experimental_v1.0.0.deb ставятся в /opt/mylib/experimental

myapp_experimental_v1.0.0.deb ставятся в /opt/myapp/experimental

можно иметь одновременно и стабильную и uptoday версию одновременно сразу.

vtVitus ★★★★★ ()
Последнее исправление: vtVitus (всего исправлений: 2)
Ответ на: комментарий от vtVitus

можно иметь одновременно и стабильную и uptoday версию одновременно сразу.

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

V1KT0P ★★ ()

Собирать пакет .deb/.rpm в Docker контейнере для каждого дистра. cmake же везде есть.

Решения для всех дистров ты попросил не называть, что ожидаешь?

И не надо вот этой C++шной статической линковки, посмотри как говняно работает сборка unetbootin на Debian 10, там шрифты в кашу.

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

я не думаю, что у вас для каждой компании своя версия, иначе вы скоро повеситесь с поддержкой. Для единичный случаев, вы можете использовать отдельный репозиторий и познакомиться с apt policy, ну или в лоб в jira можете выложить для конкретной компании предварительный релиз с заказанной фичей.

Ваше, конечно, дело, но распространение через репо даёт общий для всех подход и понятную для всех модель распространения по. Скачка по ссылке уже при 10 клиентах даёт ни с чем не сравнимый геморрой в поддержке.

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

Задача в общем случае нерешаема, т.к. например в одном дистрибутиве может быть одна версия ядра Linux,

Спасибо за предупреждение, посмотрел логи сборки glibc в Ubuntu 20.04: собирается под ядро 4.4 с включенной поддержкой ядер до 3.2. Вполне неплохо.

V1KT0P ★★ ()
  1. выкладывать сборку для какой-то одной наиболее популярной убунты, а красноглазые себе в генту сами нужные либы наковыряют.

  2. собрать в докере на древней убунте, и скопировать все зависимости в папку с прогой, указав туда LD_LIBRARY_PATH / rpath / что там еще надо

  3. забить на линукс, пусть запускают через wine

(если что, я лично в персональном проекте использую вариант [1], а на работе другие люди избрали путь [6], но вообще это адский ад, и на сегодняшний день я бы выбрал [8])

waker ★★★★★ ()

не факт что возможно будет последние версии Qt5 собрать под Ubuntu 16.04

ей 4 года. не так уж много людей сидят на позапрошлом LTS. действительно хочется потратить недели-месяцы работы ради десятка человек?

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

я не думаю, что у вас для каждой компании своя версия, иначе вы скоро повеситесь с поддержкой. Да, на данный момент например всего 4 версии для разных групп под линукс.

Для единичный случаев, вы можете использовать отдельный репозиторий и познакомиться с apt policy, ну или в лоб в jira можете выложить для конкретной компании предварительный релиз с заказанной фичей.

Всё это подразумевает отдельные телодвижения от пользователей.

Ваше, конечно, дело, но распространение через репо даёт общий для всех подход и понятную для всех модель распространения по.

Куча реп для разных дистрибутивов, не особо удобно. Один бинарь для всех вот удобная и понятная модель. А то сейчас под линукс поддерживается только то, что совместимо с Ubuntu 16.04 или Ubuntu 18.04. Сейчас всем пользователям с другими дистрибутивами просто отказываем, ибо начальство подсчитало что их поддержка не стоит того.
Все равно для мака и винды пришлось делать автообновление, и уже поимев проблемы с deb пакетами решили и под линукс сделать так-же как и под остальные ОС.

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

действительно хочется потратить недели-месяцы работы ради десятка человек?

Пока они платят и их достаточно для поддержки то да. Для винды то-же приходится поддерживать старье. Поддерживаем 7 SP1, хотя находились и те кто пытался ставить на 7 без SP1, а один так вообще на XP.

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

После того как собранное приложение на 16.04 затем некорректно работает на 18.04

загадками пишешь, нам догадываться что не работает ?
у меня работает собранное на 16.04 на 20.04

И никто ничего руками не хочет делать, всё должно автоматически делаться.

игнорируй таких дураков, сам так делаю )

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

загадками пишешь, нам догадываться что не работает ? у меня работает собранное на 16.04 на 20.04

Я уже и не вспомню что именно. Программа ведь построена на активном использовании ОС специфических вещей. Почти каждое обновление Qt привносило новые проблемы.

игнорируй таких дураков, сам так делаю )

Дык только такие и платят =).

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

Почти каждое обновление Qt привносило новые проблемы

опять загадки, какие например ?
да и возьми удобную тебе версию qt и собери её, это не сложно. таким образом не будет зависимости от разный версий в разных ОС

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

опять загадки, какие например ?

Из запоминающихся, на линуксе с KDE при установке определенной темы Qt крашился. До этого я даже и представить не мог что тема может быть причиной падения.
Или вот на маке очень странный и редкий баг иногда у некоторых пользователей происходит: часть элементов в окне становятся 100% прозрачными.
Багтрекер Qt открытый можешь посмотреть какие там баги иногда случаются.

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

в таком случаи обязательно собирай сам qt - тогда точно не будет неожиданный багов новых/старых версий
вон qtcreator носит с собой свои все либы и вполне это удобно

x905 ★★★★★ ()

Варианты AppImage, Flatpak, Snappy и остальное такое не предлагать.

а можно поитересоваться почему? вроде эти системы как раз для таких случаев и изобретали, чтобы работало в любом окружении без пересборки бинаря

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

а можно поитересоваться почему? вроде эти системы как раз для таких случаев и изобретали, чтобы работало в любом окружении без пересборки бинаря

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

V1KT0P ★★ ()