In an embedded environment that I'm working in, the following files are present:
lrwxrwxrwx 1 root root 19 Aug 23 2016 /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1 -> libjsoncpp.so.1.7.4
-rw-r--r-- 1 root root 213728 Aug 23 2016 /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1.7.4
When I need to link an executable with -ljsoncpp, I guess it's looking specifically for a file named libjsoncpp.so. Note that this file (symlink) is absent above.
Question: Is there a utility that generates the correct shared library symlink according to standard naming convention? I.e. given the above two files, is there a utility that would generate the symlink:
lrwxrwxrwx 1 root root 19 Aug 23 2016 /usr/lib/x86_64-linux-gnu/libjsoncpp.so -> libjsoncpp.so.1
?
I know that I can generate the file with ln -s..., but an offhanded comment I overheard led me to believe that there's a Linux utility that does this, and if so, I'd rather defer to an existing standard/widely used tool rather than manually doing it myself, i.e. to avoid pebkac errors like typos, etc. I have not been able to find any reference online to such a tool, and the original source I overheard the comment from is no longer available.
答案1
The .so symlink with no version number, used by the linker, is generally created as part of the library install process. I.e., by the project's Makefile, or CMake, or some other build tool.
Distributions typically split libraries into separate runtime and development packages. The un-versioned .so goes into the dev package because it's only used when linking against the library.
The best solution is to install the dev package that goes along with the runtime package the provides the library. From the date/size/version in your ls output, looks like your libjsoncpp is from Debian Buster. So the right solution in your case is to install the libjsoncpp-dev package.