Dissecting Shared Libraries
By Peter Seebach2005-03-22
Get to know your shared library
|
|
Shared libraries use version numbers to allow for upgrades to the libraries used by applications while preserving compatibility for older applications. This article reviews what's really going on under the book jacket and why there are so many symbolic links in /usr/lib on a normal Linux™ system.
Shared libraries are a fundamental component for the efficient use of space and resources on a modern UNIX® system. The C library on a SUSE 9.1 system is made up of about 1.3 MB. A copy of that library for every program in /usr/bin (and I have 2,569!) would take up a couple of gigabytes of space.
Of course this number is inflated -- statically linked programs would incorporate only those parts of the library that they use. Nonetheless, the amount of space tied up by all those duplicate copies of printf() would give the system a very bloated feel.
Shared libraries can save memory, not just disk space. The kernel can keep a single copy of a shared library in memory, sharing it among multiple applications. So, not only do we only have one copy of printf() on the disk, we only have one in memory. That has a pretty noticeable effect on performance.
In this article, we'll review the underlying technology used for shared libraries and the way in which shared library versioning helps prevent the compatibility nightmares that naive shared library implementations have had in the past. First, a look at how shared libraries work.
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 |