What is * .so. *. * libs

Question

When I do ls -l in /usr/lib , I see a lot of lib with the extension "sameName.so.*.*" .

• What is the meaning of these extensions?
• Why are soft links created? what is their use?

One example will help in understanding.

Answer 1

This is a trick used for versions of shared object files. This is a way to avoid the terrible DLL hell that arose because of the lazy link.

The advantage of lazy binding (or late binding) is that the components of your executable can be changed without actually binding those executables. This allows you to fix errors in third-party components without having to send a new executable file, among other things.

The disadvantage is the same as the advantage. Your executable may find that the assumptions made regarding the base libraries have been changed, and this can cause all kinds of problems.

A version of shared objects is one way to avoid this. Another would not be to separate objects at all, but it also has pros and cons, which I will not enter here.

As an example, suppose you have version 1 of xyz.so You have a file and a symbolic link to this file:

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

Now, when you create the exe1 by linking it to xyz.so , it will follow a symbolic link so that it xyz.so.1 in the executable as the thing that it should load at runtime.

Thus, when updating a shared library:

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

your source executable exe1 will download version 1 of the shared object.

However, any executable files that you are creating now (for example, exe2 ) will be associated with version 2 of the shared object.

---

The actual implementation details may vary slightly (I'm basing my answer on earlier UNIX, and Linux seems to make version control a little more reasonable than just following the symlinks). IBM developerWorks has a good article on how to do this here .

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

Thus, you may encounter a 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 having soname of xyz.so.1 .

When the linker references in xyz.so , it follows the links until xyz.so.1.5 and uses soname xyz.so.1 to store in the executable. Then, when you run the executable, it tries to download xyz.so.1 , which will point to a specific xyz.so.1.N (not necessarily version 1.5).

So, you can install xyz.so.1.6 and update the xyz.so.1 link to point to it, and instead the already linked executables will be used.

One of the advantages of this multi-level method is that you can have several potentially incompatible libraries with the same name ( xyz.so.1.* , xyz.so.2.* ), But in each major version you can freely Update them as they are intended for compatibility.

When you link new executables:

• Those who contact xyz.so will receive the latest version of the latest version.
• Others associated with xyz.so.1 will receive the latest small version of a specific major version.
• Other links related to xyz.so.1.2 will receive a specific minor version of a specific major version.

Answer 2

This is a schema for shared libraries . Each library should have 3 names:

• Real name: name of the actual library libfoo.so.1.2.3
• "SONAME": the name recorded in the executable, and the name of the dynamic linker is looking for, libfoo.so.1.2 . This name is actually written inside the library binary itself and will be written to the executable file during the connection. Usually this is a symbolic link to the real name of the library (usually the latest version).
• Linker Name: The name you give the linker when you create your program. Usually refers to the latest version of SONAME.

Example

Say you have libfoo version 1 installed: libfoo.so - libfoo.so libfoo.so.1.0 libfoo.so.1.0.0 . You create your bar program with -lfoo . it now references libfoo and loads libfoo.so.1.0 at runtime due to SONAME. Then you upgrade to the corrected but binary compatible libfoo.so.1.0.1 by replacing the real binary. bar still refers to libfoo.so.1.0 and does not need to be rebuilt.

Now imagine that you want to create a new baz program that uses incompatible changes in libfoo v1.1. You install a new version, and your system now has two versions installed in parallel:

• libfoo.so.1.0 → libfoo.so.1.0.1
• libfoo.so → libfoo.so.1.1 → libfoo.so.1.1.0

The link builder name has been updated to the latest version (this is the version corresponding to the headers installed in /usr/include ).

You create a baz and it references libfoo.so and loads libfoo.so.1.1 at runtime. Not that bar is still working with libfoo.so.1.0 and does not need to be updated.