Using Shared Libraries


The easiest way to use a shared library is to ignore the fact that it is a shared library. The C compiler automatically uses shared libraries instead of static ones unless it is explicitly told to link with static libraries. However, there are three other ways to use shared libraries. One, explicitly loading and unloading them from within a program while the program runs, is called dynamic loading.

Using Noninstalled Libraries

When you run a program, the dynamic loader usually looks in a cache (/etc/ld.so.cache, created by ldconfig) of libraries that are in directories mentioned in /etc/ld.so.conf to find libraries that the program needs. However, if the LD_LIBRARY_PATH environment variable is set, it first dynamically scans the directories mentioned in LD_LIBRARY_PATH (which has the same format as the PATH environment variable) and loads all the directories it finds in the path, before it looks in its cache.

This means that if you want to use an altered version of the C library when running one specific program, you can put that library in a directory somewhere and run the program with the appropriate LD_LIBRARY_PATH to access that library. As an example, a few versions of the Netscape browser that were linked against the 5.2.18 version of the C library would die with a segmentation fault when run with the standard 5.3.12 C library because of a more stringent enforcement of malloc() policies. Many people put a copy of the 5.2.18 C library in a separate directory, such as /usr/local/netscape/lib/, move the Netscape binary there, and replace /usr/local/bin/netscape with a shell script that looks something like this:

#!/bin/sh  
export LD_LIBRARY_PATH=/usr/local/netscape/lib:$LD_LIBRARY_PATH  
exec /usr/local/netscape/lib/netscape $* 

Preloading Libraries

Sometimes, rather than replacing an entire shared library, you wish to replace only a few functions. Because the dynamic loader searches for functions starting with the first loaded library and proceeds through the stack of libraries in order, it would be convenient to be able to tack an alternative library on top of the stack to replace only the functions you need.

An example is zlibc. This library replaces file functions in the C library with functions that deal with compressed files. When a file is opened, zlibc looks for both the requested file and a gzipped version of the file. If the requested file exists, zlibc mimics the C library functions exactly, but if it does not exist, and a gzipped version exists instead, it transparently uncompresses the gzipped file without the application knowing. There are limitations, which are described in the library's documentation, but it can trade off speed for a considerable amount of space.

There are two ways to preload a library. To affect only certain programs, you can set an environment variable for the cases you wish to affect:

LD_PRELOAD=/lib/libsomething.o 
exec /bin/someprogram $* 

However, as with zlibc, you might want to preload a library for every program on the system. The easiest way to do that is to add a line to the /etc/ld.so.preload file specifying which library to preload. In the case of zlibc, it would look something like this:

/lib/uncompress.o  

Legal Disclaimer

Our website is not responsible for the information contained by this article. Webworldarticles.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.


This article was sent to us by: Lorent Konenbal at 08042007

Related Articles

1. Installing Shared Libraries
The ldconfig program does all the hard work of installing a shared library. You just need to put the files in place and run ldconfig. Follow these steps: ...

2. What's a Linux Process
What exactly is a process? In the original Unix implementations, a process was any executing program. For each program, the kernel kept track of ...

3. POSIX Interfaces
POSIX Required Types POSIX defines several typedefs defined in the header file <sys/types.h> and used for many arguments and return values. These typede...

4. Common Linux Security Holes
Now that we have looked at ways of reducing the potential impact of insecure code, we go over some of the most common programming mistakes that lead to security problem...

5. Emax vs. vi Unix text editors
Unix developers have traditionally held strong and diverse preferences, especially about editors. Many programmers' editors are available for you to try; the two ...

6. Running a Linux Program as a Daemon
Programs that are designed to run as system daemons need to be a little careful how they become daemons to get all of the details right. Here is a list of things that s...

7. Linux Console Capabilities
The Linux console, like most terminals, is modal: Its response to data depends on what mode it is in. By default, it prints on the screen the characters you send ...

8. Notional Lineage of Unix Systems
Although the major portions of Linux comprise code developed independently of traditional Unix source bases, the interfaces that Linux provides were influenced heavily ...

9. What is the GNU Debugger
Gdb is the Free Software Foundation's debugger. It is a good command-line debugger, on which several tools have been built, including Emacs' gdb mode, the graphical ...

10. Development of Linux
In 1991, Linus Torvalds, at that time a student at the University of Helsinki, started a project to teach himself about low-level Intel 80386 programming. At the time, ...