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

Просто соберите свою прогу с официально собранным Qt и всё. Для надежности можно на старой убунте собрать. Типа 16.04. Этого достаточно.

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

Правильно. А решение то простое - Qt4.

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

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

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

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

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

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

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

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

4.2

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

Так и запишем - жадный пропиетарщик

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

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

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

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

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

Да.

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

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

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

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

А в чём проблема все нужные либы собрать в tar.xz и распаковывать всё разом в /opt? Единственное, от чего ты будешь в этом случае зависеть - это libc. Но её не переименуют и не удалят.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 версию одновременно сразу.

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

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

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

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

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

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

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

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

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

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

Проприетарное говно распространять других способов не существует.

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

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

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

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

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

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

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

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

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

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

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

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

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

нормально

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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