Issue
I recently took over some RPM work while one of our colleagues is away. During the post installation step, the RPM installs some libraries in a particular location, writes a file to /etc/ld.conf.so.d/ containing the path to these files, and then runs "ldconfig". But when the call is made, there are quite few messages stating that: "libXYZ.so* is not a symbolic link".
I looked at the files and the sym links are not set up correctly. E.g., libA.so.1 and libA.so.1.1 are identical files, instead of libA.so.1->libA.so.1.1. Whenever ldconfig is run on a system with the RPM installed, these messages are shown.
Now for no particular reason, I tried replicating this by creating a shared library called libmylib.so.1.1. Then I created another file called libmylib.so.1 which was identical to the previous file. I added a test.conf file to /etc/ld.conf.so.d which contains the path to these shared libraries, and then ran ldconfig. But I didn't see any of these "not a symlink" messages. Instead ldconfig set up two symlinks to both these files. Is that message displayed only under particular circumstances?
Also, when I'm installing shared libraries, do I need to setup the links such as:
linker name -> so name -> real name
manually? And then run ldconfig?
This is my first time working with RPM and installing shared libraries, so any input would be appreciated.
Thanks
Solution
Common practice is to make symbolic links to relate the library version and soname to the name used when building/linking a program. Here are a few comments on that:
ldconfig expects that there is only one actual file. Here are a few places where this question has been asked:
- Always getting “not a symbolic link” message, while installing any package
- ldconfig : /usr/lib/libstdc++.so.6 is not a symbolic link + mysql
Usually, problems in this area are due to improper updating of the symbolic links. But an incorrect build-script can be the problem as well.
Answered By - Thomas Dickey Answer Checked By - Gilberto Lyons (WPSolving Admin)