Help with clarification on shared library naming convention
My understanding is that for shared libraries there is usually a set of symbolic links to facilitate applications finding the right version. For example
libfoo.so.1.1.1 (actual library) libfoo.so.1.1 -> libfoo.so.1.1.1 libfoo.so.1 -> libfoo.so.1.1.1 My question is that for library libX.so.a.b.c are the symbolic links: libX.so.a.b libX.so.a considered necessary and should be created by ldconfig ? My experience is with compiling the GLEW library locally and then running make install but it only created the following: libGLEW.so.1.9.0 (actual shared library) libGLEW.so.1.9 -> libGLEW.so.1.9.0 libGLEW.so -> libGLEW.so.1.9.0 It's missing the libGLEW.so.1 -> libGLEW.so.1.9.0 which I would think should exist as well. Running ld config also does not create this libGLEW.so.1 Is this expected behavior ? If so what is the rule/explanation about this ? Thanks |
Hi,
I think you've got this kind of backward. The symbolic links are there for building against a library not running running against it. You'll get the symbolic links from libFoo.so.x.y to libFoo.so.x and libFoo.so if you install the libFoo-dev package (libFoo.so.x.y will be in the libFoo package). At run time a given the program knows to look for the same libFoo.so.x.y that was used when it was built, but the build itself just looks for libFoo.so. Evo2. |
Thanks for the reply,
So you are saying that in the case above there will never be any app that will try to look for libGLEW.so.1 ? Or should I say is it illegal/against convention that an app can be linked to a library with only major version number such as libGLEW.so.1 instead of libGLEW.so.1.9 ? How does ldconfig determine that only the libGLEW.so.1.9 symbolic link should be created and not libGLEW.so.1 ? I just would like to find out the logic/reasoning behind it. Thanks again |
Hi,
Quote:
Quote:
Quote:
Evo2. |
All times are GMT -5. The time now is 10:52 PM. |