In general, there are two types of library files: dynamic libraries and static libraries.

I. Dynamic Libraries

Dynamic libraries (also known as shared libraries) are pieces of compiled code which are loaded by the runtime linker /lib/ld.so when an executable is run. This is analagous to the .dll files of MS Windows. In terms of efficiency, this saves:

• Hard drive space: different executables can share the same code
• RAM: the kernel can store one copy of the library in memory and this can be shared between executables
• Time: upgrading involves compiling less code if you don't have to recompile the libraries.

Dynamic libraries are named, by convention, with the string so, followed by a version number. Examples are:

libc.so.6	The C library. Don't delete it. :)
libcrypt.so.1	The encryption library for shadow systems.
libncurses.so.4.2	The new curses library routines.

II. Static Libraries

Static libraries are bolted into the executable rather than being somewhere else on the system and loaded into the executable by ld.so. The pro is that the executable is self contained; it doesn't depend on code elsewhere on the system, and not subject to missing libraries. You can give this code to anyone else and it's guarenteed to work. The con is that the executable is larger than necessary and you can't share code between different programs.

Static libraries are named, by convention, with the string .a appended to the library name. Some examples are:

libgtk.a	Graphics libraries for GIMP and many other X apps.
libcrypt.a	The encryption library for shadow systems.
libvga.a.	Library for full screen [S]VGA graphics.

III. Comparison Between Dynamic and Static Libraries

Programs that use static libraries that were bolted into them should be slightly faster than programs that have to use ld.so to load in dynamically linked code. I've seen people say that the order of magnitude of startup time difference is abot 5%. However, it has to be kept in mind that one of the benefits of dyanmic libraries is that in a good case scenario, the code is already loaded into memory. In fact, for libc, this is always going to be true. If you tried to load a statically linked netscape, you'd have to wait consderably longer for it to load. The answer to which one is faster is `it depends'. But all in all, it's a safe bet to say that a program will be faster with dynamic libraries since chances are good that the code you need is already in memory.

IV. Important Files/Executables

The program /lib/ld.so is responsible for linking dynamic libraries for an executable. It searches for library files in the following order:

1. In directories listed by the environment variable LD_LIBRARY_PATH unless the executable is setuid/setgid, in which case the environment variable is ignored.
2. In directories listed in the file /etc/ld.so.cache. See below.
3. In /usr/lib
4. In /lib

There's a very good reason why ld.so doesn't search /usr/local/lib for dynamic libraries. I would tell you, but then I'd have to kill you. Some things were just not meant for mere mortals to know...

The file /etc/ld.so.cache contains a compiled list of directories to search for libraries and an ordered list of candidate libraries. It's created by /sbin/ldconfig.

The program /sbin/ldconfig is run automatically (/etc/rc) at boot or manually by the user after compiling libraries (it's a good idea to ALWAYS run ldconfig after installing software). ldconfig generates the file /etc/ld.so.cache. It searches /lib, /usr/lib and all the directories listed by /etc/ld.so.conf.

The configuration file /etc/ld.so.conf lists all the directories that ldconfig is to search for libraries to generate ld.so.cache. If you ever put library files in a non-standard directory (like /home/lib) you should add that directory to the end of ld.so.conf and rerun ldconfig.

V. Cool Utilities

Many programs require dynamic libraries to be present on your system so the library's code can be used by the program. How can you find out which dynamic libraries are required by any given program? There's two ways.

You can use strace. For an example, find xmms, xcalc or xpaint on your system using the locate command. Try the following command:

quit the program and you'll find a file named LOG was left behind. Load up LOG with your favorite text editor and pour through the output, searching for the string so. Can you see which libraries are being called by xcalc (or whichever program you decided to use)? Can you also see some of the files mentioned above like ld.so.cache or libc.so? You also might see some interesting things, like a search for a library in one directory ends up with a "file not found" condition, so the program searches for the same library in another location. Here is what that looks like (for xcalc on my system):

Apparenlty, libXext.so.6 is not located in /usr/local/rvplayer5.0, but ld.so found it in /usr/X11R6/lib. Fortunately, there's an easier way to find this information. Try:

(the full pathname is required). ldd will respond with:

Jumpin' Jehosephat! ldd even finds the location of the library file for you! How's that for service?

VI. End Notes

So when you write a hello world program and compile it with gcc, are you using dynanmic or static libraries? gcc uses dynamic libraries, unless you give the -static option to the linker. As an example, here is my hello world program:

after compiling it with:

% gcc try.c

here is what ldd has to say about a.out:

% ldd a.out

libc.so.6 => /usr/lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Now let's compile it with static libraries:

and here's what ldd has to say about the new executable:

% ldd a.out

not a dynamic executable

See? This is theory in action!