Missing symbolic link in /usr/local/lib

Question

For my embedded linux (TI AM335x) board, I have a SDK containing subfolders sysroot and filesystem. E.g. for libz:

sysroot/.../usr/lib contains:

libz.so         # symbolic link to libz.so.1.2.7
libz.so.1       # symbolic link to libz.so.1.2.7
libz.so.1.2.7

filesystem/usr/lib/ contains

libz.so.1       # symbolic link to libz.so.1.2.7
libz.so.1.2.7

The file system does not contain the symbolic link libz.so --> libz.so.1.2.7. But my linker want it. So I added it. My questions: Is there any common reason not provide such symbolic links? Which goal is achieved by that?

Answer 1

The reason for this is so programs linking to the library can specify just a "soname", which is linked to the "real name" of the library. If you decide to upgrade the library, the linker now links to the latest version instead of always having to change the linker configuration. If you want more information about this, check here.

Answer 2

 Is there any common reason not provide such symbolic links? Which goal is achieved by that?

The only reason for concern is if there is a library API change between the symlink version of the library and the installed library. In that case, you will either get linker error if a needed function name isn't found, or you will get broken code if all names are the same, but operation of a given function has changed in between versions. When you manually create symlinks to shared libraries, you take on the responsibility to insure that the library calls you need are the same between the shared object library versions. Generally, when a library changes its soname (shared object name), it does so because there is some underlying change in the library that users of that library need to be aware of and confirm proper use. The fact that you need libz.so and your system has libz.so.1 indicates such a change or soname bump occurred. You need to confirm that the features you need from libz.so are present and remain unchanged in libz.so.1. (most of the time libraries are backwards compatible, but at times they are not [e.g. libpng-1.2 and libpng-1.4])

That is the whole point with sonames. When you find yourself in the situation you are in either needing to create a symlink manually, or downgrade libz to get the needed libz.so -- the soname change tells you that there have been library changes between libz.so and libz.so.1 so it is up to you to verify you can use libz.so.1 symlinked to libz.so in the manner you are attempting to do.

Why should you even need the symlink? Why shouldn't your code be happy just using libz.so.1 in place of libz.so without the symlink? The code you are compiling is looking for libz.so. As you have found, it is not present on your system. By providing the libz.so -> libz.so.1 symlink you allow your code to find libz.so.1 through the name libz.so without modifying your code. Creating the symlink is basically just a hack to work-around fixing your code to work with libz.so.1. Depending on your access to the code on either system, that may be necessary, but the proper way to handle this situation is to update both systems and the code to build with/use the current library libz.so.1

All that being said, if the changes to libz.so.1 don't affect any part of libz.so you need to use, then the symlink works just fine.