LINUX.ORG.RU

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

 , , ,


0

2

Здравствуйте. Столкнулся с такой проблемой за неимением опыта работы с кастомными библиотеками.

Допустим, я написал библиотеку. Положил header-файлы в /usr/include/mylibrary, положил *.so файлы в /usr/lib/mylibrary, в Qt проекте прописал библиотеку, все компилируется, все хорошо. Но чтобы запустить этот бинарник приходится прописывать что-то подобное:

LD_LIBRARY_PATH="/usr/lib/mylibrary" ./program

Прописал ldconfig -v, моей либы там нет.

Файл называется правильно, ну т.е. условно: /usr/lib/mylibrary/libmylibrary.so.1.0.0 и symlink’и на *.so.1.0, *.so.1 и *.so.

Подскажите, пожалуйста, что делать?



Последнее исправление: thm (всего исправлений: 1)

Либо ты:

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

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

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

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

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

thm
() автор топика

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

annulen ★★★★★
()

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

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

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

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

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

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

thm
() автор топика
Последнее исправление: thm (всего исправлений: 5)
Ответ на: комментарий от peregrine

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

Если СПО

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

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

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

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

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

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

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

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

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

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

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

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

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

monk ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.