12

Sometimes, for one reason or another, a program hasn't specified or included all its dependencies correctly, and starting it up results in errors indicating missing dependencies. A typical error is something like:

cannot open shared object libudev.so.0

I see a lot of answers advising people to work around such problems by making symlinks in /usr/lib or other system locations, and this does seem to often solve the problem. But I see an equal number of comments advising people that it's a bad idea. Here's one answer that's representative.

Under what circumstances is it acceptable to symlink a library to make a program work? Never? Sometimes? What if you delete the symlink after you finish running the program?

What are the the consequences of doing this?

Community
  • 1
John Feminella
  • 1,472

1 Answers1

12

The problem with creating these links is that they aren't managed in any meaningful way. If that library is removed, the link becomes broken. If the library is upgraded, it may encounter an error because of the link that it doesn't expect to be there.

Also, you are essentially lying to the system. In the linked example, you are pretending that libudev.so.1 is actually libudev.so.0. They are named differently for a reason (different versions of the library). While this may work just fine for some programs, there is the potential that differences between the versions could cause issues (such as a segfault or other unexpected behavior).

So if you are specifically creating this link just so a program will run, and you know that you will remove it later, you address the first issue but not the second. While this does address the primary issue, it is not ideal.

The ideal solution is of course to install the right version of the library (the accepted answer on your linked example), or to compile the program against the version you have.

Nattgew
  • 2,100