Можно ли (или нет) использовать библиотеки ссылок для преодоления ошибок «не удается открыть общий объект»?
Иногда, по той или иной причине, программа не указала или не включила все свои зависимости правильно, и запуск ее приводит к ошибкам, указывающим на отсутствующие зависимости. Типичная ошибка выглядит примерно так:
cannot open shared object libudev.so.0
Я вижу много ответов, советующих людям обойти такие проблемы, создавая символические ссылки в /usr/lib или других местах системы, и, похоже, это часто решает проблему. , Но я вижу такое же количество комментариев, которые советуют людям, что это плохая идея. Вот один ответ, который является представительным.
При каких обстоятельствах допустимо использовать символическую ссылку на библиотеку, чтобы заставить программу работать? Никогда? Иногда? Что если вы удалите символическую ссылку после завершения работы программы?
Каковы последствия этого?
1 ответ
Проблема с созданием этих ссылок состоит в том, что ими не управляют никаким значимым способом. Если та библиотека удалена, ссылка становится поврежденной. Если библиотека обновлена, она может встретиться с ошибкой из-за ссылки, которой она не ожидает быть там.
кроме того, Вы по существу лжете системе. В связанном примере Вы притворяетесь, что libudev.so.1 на самом деле libudev.so.0. Их называют по-другому по причине (различные версии библиотеки). В то время как это может работать просто великолепно для некоторых программ, существует потенциал, что различия между версиями могли вызвать проблемы (такие как segfault или другое неожиданное поведение).
Поэтому при специфическом создании этой ссылки именно так программа будет работать, и Вы знаете об удалении его позже Вы решаете первую проблему, но не второе. В то время как это действительно решает основную проблему, это не идеально.
идеальное решение должно, конечно, установить правильную версию библиотеки (принятый ответ на Вашем связанном примере), или скомпилировать программу против версии, которую Вы имеете.