CODEWITHSUNDEEP
linuxshared-libraries
nisah
nisah

Reputation: 2530

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

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 ?

Upvotes: 42

Views: 18696

Answers (4)

paxdiablo
paxdiablo

Reputation: 881323

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.

Upvotes: 49

shuyan
shuyan

Reputation: 109

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?)

Upvotes: 0

guest
guest

Reputation: 1

  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

Upvotes: -1

Didier Trosset
Didier Trosset

Reputation: 37427

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.

Upvotes: 2

Related Questions