Dissecting Shared Libraries

By Peter Seebach
2005-03-22

Compatibility's not just for relationships

This means that the library you end up being linked to had better be compatible with the code that's calling it. With a statically linked executable, there is some guarantee that nothing will change on you. With dynamic linking, you don't have that guarantee.

What happens if a new version of the library comes out? Especially, what happens if the new version changes the calling sequence for a given function?

Version numbers to the rescue -- a shared library will have a version. When a program is linked against a library, it has the version number it's designed for stored in it. The dynamic linker can check for a matching version number. If the library has changed, the version number won't match, and the program won't be linked to the newer version of library.

One of the potential advantages of dynamic linking, however, is in fixing bugs. It'd be nice if you could fix a bug in the library and not have to recompile a thousand programs to take advantage of that fix. So sometimes, you want to link to a newer version.

Unfortunately, that creates some cases where you want to link to the newer version and some cases where you'd rather stick with an older version. There is a solution, though -- two kinds of version numbers:

• A major number indicates a potential incompatibility between library versions.
• A minor number indicates only bug fixes.

So under most circumstances, it is safe to load a library with the same major number and a higher minor number; consider it an unsafe practice to load a library with a higher major number.

To prevent users (and programmers) from needing to track library numbers and updates, the system comes with a large number of symbolic links. In general, the pattern is that

libexample.so

will be a link to

libexample.so.N

in which N is the highest major version number found on the system.

For every major version number supported,

libexample.so.N

will be a link in turn to

libexample.so.N.M

in which M is the largest minor version number.

Thus, if you specify -lexample to the linker, it looks for libexample.so which is a symbolic link to a symbolic link to the most recent version. On the other hand, when an existing program is loaded, it will try to load libexample.so.N in which N is the version to which it was originally linked. Everyone wins!

Tutorial Pages:
» Get to know your shared library
» How shared libraries work
» Compatibility's not just for relationships
» To debug, first you must know how to compile
» Modifying the dynamic linker search path
» Linking Mozilla
» Learning more about shared libraries
» Resources

First published by IBM DeveloperWorks

Related Tutorials:
» How to Install PHP 5 on Linux
» How to Install Apache 2 on Linux
» How to Install MySQL 5.0 on Linux
» SMB Caching
» Mound --Bind
» Tar Wild Card Interpretation