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

Всем привет, пишу ПО для Linux и я хочу понять, какие зависимости линковать статически, а какие динамически, а также, если линковать динамически, то поставлять .so файлы вместе с ПО в своей директории /lib или же доверять скачивание в систему пакетным менеджерам?
Как я понял динамические библиотеки в основном лучше, так как можно обновлять их не перекомпилируя свое ПО (и это огромный плюс).
Если доверять скачивание в систему пакетному менеджеру, то возникает проблема с тем, что на разных дистрибутивах и версиях linux могут быть разные версии используемых библиотек, тогда мне придется использовать наиболее древние версии этих библиотек?
В общем вопросы можно сформулировать так:
1. Линковать либы всегда динамически?
2. Если динамически, то как бороться с отсутствием нужных для работы ПО зависимостей на разных дистрибутивах и их версиях?
3. Норм вместе с ПО таскать зависимости .so?
Спасибо за ответ!

0

Сообщение от Arqlem и я хочу понять, какие зависимости линковать статически, а какие динамически

Если есть выбор - динамически.

Сообщение от Arqlem поставлять .so файлы вместе с ПО в своей директории /lib или же доверять скачивание в систему пакетным менеджерам?

Второе.

Сообщение от Arqlem то возникает проблема с тем, что на разных дистрибутивах и версиях linux могут быть разные версии используемых библиотек, тогда мне придется использовать наиболее древние версии этих библиотек?

Не обязательно.

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

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

1

Arqlem, бороться с отсутствующими зависимостями можно и с помощью Flatpack/Snap/AppImage

0

Сообщение от Arqlem Линковать либы всегда динамически?

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

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

Сообщение от Usaga Flatpack/Snap/AppImage

0

Сообщение от Usaga бороться с отсутствующими зависимостями можно и с помощью Flatpack/Snap/AppImage

Можно, но в общем-то это крайний случай, когда ничего более разумного сделать не получается. Ибо ресурсы жрет в безумных количествах, да и просто противоестественно для *nix.

0

Сообщение от Pphantom Ибо ресурсы жрет в безумных количествах

Разве? Можешь какую-то ссылку кинуть на некое исследование. Я без домоганий, правда интересно.

Сообщение от Pphantom а и просто противоестественно для *nix.

А это плевать вообще. Либо ОС полезна, либо она следует неким принципам.

0

Сообщение от Usaga Разве? Можешь какую-то ссылку кинуть на некое исследование.

Ссылок на исследования нет, но могу привести реальный пример того, что он в какой-то мере прав.

Например, если в магазе Fedora Linux перейти на страничку Gimp, то можно увидеть, что размер FLATPAK из Fedora Linux равен 584 МБ, размер FLATPAK из Flathub равен 500 МБ, а вот размер системного RPM пакета с динамической линковкой всего 80 МБ. Разница значительная. На винде установщик GIMP весит всего 296 МБ, хотя там тоже со всеми зависимостями.
То есть, получается, что FLATPAK довольно-таки весят много.

0

Сообщение от Royal_X Например, если в магазе Fedora Linux перейти на страничку Gimp, то можно увидеть, что размер FLATPAK из Fedora Linux равен 584 МБ, размер FLATPAK из Flathub равен 500 МБ, а вот размер системного RPM пакета с динамической линковкой всего 80 МБ. Разница значительная. На винде установщик GIMP весит всего 296 МБ, хотя там тоже со всеми зависимостями. То есть, получается, что FLATPAK довольно-таки весят много.

Количество и размеры зависимостей могут сильно отличаться в зависимости от ОС, платформы и т.д. Поэтому сравнивать размер некорректно.

0

Сообщение от Usaga Разве? Можешь какую-то ссылку кинуть на некое исследование. Я без домоганий, правда интересно.

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

Ну и, да, любое сравнение размеров пакетов, вроде приведенного Royal_X, показывает то же самое. Из собственного недавнего опыта - понадобился RStudio, которому неудачно что-то отломали в сборке под OpenSUSE Thumleweed. Решать проблему надо было быстро, поэтому воспользовался snap... разница в пять раз, 200М в первом случае и 1G во втором.

Сообщение от Usaga А это плевать вообще. Либо ОС полезна, либо она следует неким принципам.

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

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

0

Программы на винде обычно поставляются со всеми библиотеками или используют статическую линковку. Если они и ссылаются к каким-то dll, то обычно только к системным, относящимся к винде, включая Visual C++ Redist, DX и прочее.
Исторически, винда любит статическую линковку. Если же используется динамическая линковка, то, как уже выше написал, все dll обычно поставляются вместе с программой, даже если они дублируются. На винде принято, что каждое приложение имеет собственную папку, где он лежит со всеми зависимостями.
И этот подход я считаю, что более правильный. Причина популярности такого подхода на винде кроется в "DLL hell" - явление, которое есть и на других платформах, но там оно известно как "ад зависимостей".
Пингвиновская идея, что если приложения будут использовать одни и те же зависимости, хороша в теории, но на практике постоянно приводит ко всяким конфликтам, когда одно приложение хочет одну версию той или иной зависимости, другая - другую, и обе версии установить нельзя из-за конфликта. Конечно, во многих случаях эти конфликты можно решить, но есть одно НО. Многое время линукс использовали только гики, задроты, хакеры и прочие звери, для которых решить этот конфликт было минутным делом. Но постепенно линукс стали использовать и прочие касты совершенно обычных юзверей, которые отказывались от винды и яблока по политическим причинам, чисто из-за взглядов. Для этих людей нужно было облегчить установку пакетов на линуксе. Во-первых, кроме пакетных менеджеров, нужно было создать менеджеры приложений с граф. интерфейсом. Во-вторых, установка должна была быть по одному клику и без всяких неожиданных конфликтов из-за зависимостей. И тут пришла идея создать всякие изолированные пакеты.

0