Program Library HOWTO

This is the main web site for the Program Library HOWTO. This HOWTO for programmers discusses how to create and use program libraries on Linux using the GNU toolset. A ``program library'' is simply a file containing compiled code (and data) that is to be incorporated later into a program; program libraries allow programs to be more modular, faster to recompile, and easier to update. Program libraries can be divided into three types: static libraries, shared libraries, and dynamically loaded (DL) libraries.

This document is part of the Linux Documentation Project (LDP), and distributed in various Linux distributions. However, note that the LDP's version or the version in a CD-ROM distribution may not be as current as the main (master) web site at "".


You can see the HOWTO in HTML (good for on-line browsing), PDF, ASCII Text (not recommended), or SGML (DocBook DTD) formats. You can also see the ChangeLog, and users of the SGML format may find the Makefile useful. The document includes a lot of trivial examples; you can download the examples as a tarball. Or, to try out various library approaches, you can directly view demo_dynamic.c, demo_use.c, libhello.c, and libhello.h.

If you have comments, proposed improvements, or intend to translate it to another human language, please contact me.

Other files are available here too. If you don't believe that /lib is searched before /usr/lib, you can run the test script originally developed by Michael Kerrisk at usrlib-test, which requires source files mod1.c and sltest.c. You can also view various ELF-related specifications; see and

The short article Hello from a libc-free world! (Part 1) is handy if you're trying to minimize program size... it shows how to create programs without using any standard library. If you're interested in that, look at busybox, too.

A Personal Comment about Linux' program library design

As far as I can tell, anyone who starts learning about Linux's approach to library management goes through three stages:

  1. This is kind of odd, maybe even crufty. Multiple symbolic links? Environment variable overrides?
  2. This is really odd, why do they DO it this way?
  3. It saved my bacon again! This is amazing! I love it!

Linux is the inheritor of a lot of smart thinking about library management on a system. Some systems have what's called "DLL Hell", where incompatible libraries stomp all over each other; that can make it impossible or very difficult to run some different programs simultaneously. That doesn't happen on a Linux system; its mechanisms are based on over 35 years of understanding how things can go wrong, and how to prevent them where possible, or manage them when they do. For many years, Linux systems have been able to manage many different versions of components without trouble.

Historically Linux systems have had a different problem: there's so much software, and so many components reuse other components, that it's sometimes hard to make sure that you download all the right versions of the components to install something. Today, tools like apt and yum (and portage before them) have made that problem pretty much disappear, by handling installation downloads automatically.


Translations I know of are listed here:

There may be other translations available; see the Linux Documentation Project.

I hope to mention or link to other translations as I learn about them. Please contact me before translating, so that duplicate work can be avoided (for example, perhaps multiple translators could divide the work). If one becomes available, I cannot guarantee that the translations accurately reflect the original English work; I'm sorry, but I'm simply not qualified to judge that.

Feel free to see my main web site at