Как добавить путь к библиотеке в кеш?

Либо ты:

1) кладешь библиотеку в системный каталог

2) либо показываешь системе как найти твой каталог (LD_LIBRARY_PATH)

3) либо линкуешь статически (используешь библиотеку, которая .a, вместо .so)

rpath

P.S. От себя: рекомендую третий способ, если позволяет лицензия. С ним будет минимум проблем у пользователей.

С ним будет минимум проблем

а почему?

Потому что оно статически слинкуется (в бинарик твой войдёт). Но тут всё реально от лицензии зависит.

ну, у меня весь проект под GPLv3. либы же мои

понял, тогда статическими их сделаю

Можно линковать с флагом -Wl,-rpath,/usr/lib/mylibrary

Если ты прямо в кэш хочешь добавить, создай .conf файл в /etc/ld.so.conf.d и пропиши там путь к каталогу, где твоя либа лежит. Ну, посмотри, на существующие файлы в /etc/ld.so.conf.d, понятно станет. Потом обнови кэш (от рута запусти ldconfig).

Хотя, так, конечно, лучше не делать. Тут уже про rpath писали, как вариант.

Статическая линковка хороша, когда либа линкуется в один единственный бинарник (исполняемый файл или .so). Если таких бинарников много, то они все будут включать один и тот же код, расходуя больше диска. Если они будут загружены одновременно в память, то тоже каждый процесс будет тратить память на копии кода (в отличие от динамической линковки, где один файл .so будет замаплен во все процессы). Если у тебя приложение с кучей плагинов, и каждый линукет одну и ту же .a, то это вообще кошмар.

Есть панель, есть control center. В отдельную либу решил вынести функционал, что касается работы с конфигом, чтобы этот код не дублировался. Когда будут еще какие-то компоненты, они тоже будут ессно эту либу использовать. Апплеты решил вынести тоже в отдельные библиотеки, чтобы они были отдельными файлами, а не в составе кода панели. но там все проще, они динамические, и я их подгружаю в runtime с помощью QPluginLoader. Ну, получается, таки лучше сделать ту либу динамической и компилировать с rpath, чтобы одно и то же, пусть даже и несколько раз, но не грузить?

...реально от лицензии зависит...

Та. Лицуха как раз побоку.

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

Хотя, так, конечно, лучше не делать.

Да, именно так и делается. В /etc/ld.so.conf.d уже куча файликов лежит, например:

$ cat /etc/ld.so.conf.d/qt-x86_64.conf
/usr/lib64/qt-3.3/lib

thm, тебе будут отвечать примерно до того момента, пока ты не отметишь тему как решенную.

Не надо такое рекомендовать.

• Если автор распространяет блоб, то единственный способ минимизировать проблемы у пользователей - собрать в один из этих блобоконтейнеров flatpack/snap/appimage.
• Если СПО, то динамические библиотеки проблем не вызывают, потому что невозможна ситуация когда библиотека несовместимо меняется, а софт не пересобрать. Статически же слинкованные библиотеки утяжеляют бинарник, не дают шарить код, и не дают нормально его обновлять (нельзя исправить баг или уязвимость во всей системе простым обновлением библиотеки). Ещё их сложнее линковать - некоторым линкерам важен порядок, и все транзитивные зависимости нужно указывать явно.

См. выше про статическую линковку (это для общего случая когда библиотека поставляется отдельно от приложения). В дополнение:

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

И в любом случае, не надо её класть в /usr/lib/mylibrary/libmylibrary.so.1.0.0. Клади в /usr/lib, он именно для этого предназначен. А если таки кладёшь в mylibrary/ то правильный ответ - rpath.

Ну, получается, таки лучше сделать ту либу динамической и компилировать с rpath, чтобы одно и то же, пусть даже и несколько раз, но не грузить?

Да.

Ну или наоборот, всё перечисленное собирать в один исполняемый файл (запуская разные модули в зависимости от параметров запуска, или даже в зависимости от argv[0], как у какого-нибудь busybox), и линковать всё статически, забив на лоудеры и т.д.

Если автор распространяет блоб, то единственный способ минимизировать проблемы у пользователей - собрать в один из этих блобоконтейнеров flatpack/snap/appimage.

Заменяем «блоб» на «динамическое шпагетти» и гораздо честнее получается.

Если СПО

То вообще пофик, собирайте бинарник как сами хотите.

Статически же слинкованные библиотеки утяжеляют бинарник, не дают шарить код

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

Ещё их сложнее линковать - некоторым линкерам важен порядок, и все транзитивные зависимости нужно указывать явно.

А динамические зависимости явно указывать не надо?

нельзя исправить баг или уязвимость во всей системе простым обновлением библиотеки

Немножечко сложнее, но можно, бинарнодистропроблемы.

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

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

А если библиотека собрана статически, то проблем нет.

Если же рассматриваем только изменения с полным сохранением API и поведения библиотеки, то и бинарник продолжит работать.