Question

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 ?

Answer 1

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

So you can end up with the situation:

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

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

When the linker links with xyz.so, it follows the file links all the way to xyz.so.1.5 and uses its SONAME of xyz.so.1 to store in the executable produced, so it can later bind when running.

Then, when you run the executable, it tries to load using the SONAME that was stored in the executable, xyz.so.1, and this will point to a specific xyz.so.1.N (1.5 at the moment but subject to later change, 1.6 .. 1.N).

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 (when they run).

The 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 to make 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.