How do applications resolve to different versions of shared libraries at run time?

I'm a noob to how shared libraries work on linux. I am trying to understand how do applications resolve different revisions of the same shared library at run-time on linux.

As far as I understand, a shared library has three "names", for example,

1. libmy.so.1.2 (real-name i.e. the actual obj file)
2. libmy.so.1 (SONAME, which is embedded in the actual obj file)
3. libmy.so (linker name, provided to the linker at link time and embedded in executable)

When you开发者_开发技巧 install the library via LDCONFIG, it will create the following symbolic links

• (2) => (1)
• (3) => (2)

Now lets say I compile another version of the same library with the following real-name, libmy.so.2.0. The SONAME by guidelines would be libmy.so.2.0

At application link time what is the linker name that I would provide with the "-l" flag. Following the guidelines I read (http://www.dwheeler.com/program-library/Program-Library-HOWTO/x36.html), wouldn't it have to be libmy.so and if so, how will both versions of the obj file be distinguished ?

Versioning of shared objects works as follows:

When you create a shared object, you give it both a real name and an soname. These are used to install the shared object (which creates both the object and a link to it).

So you can end up with the situation:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so.1 -> xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

with xyz.so.1.5 possessing the SONAME of xyz.so.1.

When the linker links in xyz.so, it follows the links all the way to xyz.so.1.5 and uses its SONAME of xyz.so.1 to store in the executable. Then, when you run the executable, it tries to load xyz.so.1 which will point to a specific xyz.so.1.N (not necessarily version 1.5).

So you could install xyz.so.1.6 and update the xyz.so.1 link to point to it instead and already-linked executables would use that instead.

One advantage of this multi-layer method is that you can have multiple potentially incompatible libraries of the same name (xyz.so.1.*, xyz.so.2.*) but, within each major version, you can freely upgrade them since they're supposed to be compatible.

When you link new executables:

• Those linking with xyz.so will get the latest minor version of the latest major version.
• Others linking with xyz.so.1 will get the latest minor version of a specific major version.
• Still others linking with xyz.so.1.2 will get a specific minor version of a specific major version.

Now keep that last paragraph in mind as we examine your comment:

Now lets say I compile another version of the same library with the following real-name, libmy.so.2.0. The SONAME by guidelines would be libmy.so.2.0.

No, I don't believe so. The soname would be more likely to be libmy.so.2 so that you can make minor updates to the 2.x stream and get the latest behaviour.

At application link time, if you specify -lmy, the linker will search for a file named libmy.so. It will find this file, and link you executable with it. If this file is a symbolic link, then your application will be linked with the target of the symlink.

Application link time is the place to specify which version of the dynamic library you want to use with your application.

A complement to @paxdiablo's answer bullet one:

ldconfig doesn't set up the linker names; typically this is done during library installation, and the linker name is simply created as a symbolic link to the ``latest'' soname or the latest real name.

it means xxx.so will link to a latest minor version of the latest major version dynamic library file.

I think this explains why:

• Those linking with xyz.so will get the latest minor version of the latest major version.

But I don't know how installation setup linker name and which tool make it(apt-get?)

1. Libs have different versions in the name.
2. Packages with name "lib" have only libs and have different versions in the name.
3. System will compile only with the latest library, unless you define a different one.
4. The application uses only those libraries that it needs. Check ldd , readelf.
5. Apps contain a link .so and .pc file, check rpm system for what. https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging#Devel_Packages