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

by

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.

More Related Contents:

  1. Linux error while loading shared libraries: cannot open shared object file: No such file or directory
  2. ld cannot find an existing library
  3. How to show all shared libraries used by executables in Linux?
  4. How do I view the list of functions a Linux shared library is exporting?
  5. How to specify the library version to use at link time?
  6. How do I find out what all symbols are exported from a shared object?
  7. What’s the difference between .so, .la and .a library files?
  8. What is the ‘soname’ option for building shared libraries for?
  9. Pack shared libraries into the elf [closed]
  10. Linux capabilities (setcap) seems to disable LD_LIBRARY_PATH
  11. undefined reference to symbol even when nm indicates that this symbol is present in the shared library
  12. How can I change the filename of a shared library after building a program that depends on it?
  13. library path when dynamically loaded?
  14. How to set RPATH and RUNPATH with GCC/LD?
  15. Save modifications in place with awk
  16. Why should eval be avoided in Bash, and what should I use instead?
  17. Add a prefix string to beginning of each line
  18. Can awk patterns match multiple lines?
  19. Linux PID recycling [closed]
  20. vscode “#include errors detected. Please update your includePath
  21. How to run a process with a timeout in Bash? [duplicate]
  22. Accurate calculation of CPU usage given in percentage in Linux?
  23. Escape filenames the same way Bash does it
  24. What is the default register state when program launches (asm, linux)?
  25. Can you Run Xcode in Linux?
  26. How to convert \uXXXX unicode to UTF-8 using console tools in *nix
  27. Pthread Mutex lock unlock by different threads
  28. Colour highlighting output based on regex in shell
  29. How to discover what Linux distribution is in use
  30. bash: set array env variable and de-referencing it from any shell script fails

Leave a Comment