Exercise 29: Libraries and Linking

A central part of any C program is the ability to link it to libraries that your OS provides. Linking is how you get additional features for your program that someone else created and packaged on the system. You've been using some standard libraries that are automatically included, but I'm going to explain the different types of libraries and what they do.

First off, libraries are poorly designed in every programming language. I have no idea why, but it seems language designers think of linking as something they just slap on later. Libraries are usually confusing, hard to deal with, can't do versioning right, and end up being linked differently everywhere.

C is no different, but the way linking and libraries are done in C is an artifact of how the UNIX operating system and executable formats were designed years ago. Learning how C links things helps you understand how your OS works and how it runs your programs.

To start off, there are two basic types of libraries:

• static: You made one of these when you used ar and ranlib to create the libYOUR_LIBRARY.a in the last exercise. This kind of library is nothing more than a container for a set of .o object files and their functions, and you can treat it like one big .o file when building your programs.
• dynamic: These typically end in .so, .dll or about one million other endings on OS X, depending on the version and who happened to be working that day. Seriously though, OS X adds .dylib, .bundle, and .framework with not much distinction between the three. These files are built and then placed in a common location. When you run your program, the OS dynamically loads these files and links them to your program on the fly.

I tend to like static libraries for small- to medium-sized projects, because they are easier to deal with and work on more operating systems. I also like to put all of the code I can into a static library so that I can then link it to unit tests and to the file programs as needed.

Dynamic libraries are good for larger systems, when space is tight, or if you have a large number of programs that use common functionality. In this case, you don't want to statically link all of the code for the common features to every program, so you put it in a dynamic library so that it is loaded only once for all of them.

In the previous exercise, I laid out how to make a static library (a .a file), and that's what I'll use in the rest of the book. In this exercise, I'm going to show you how to make a simple .so library, and how to dynamically load it with the UNIX dlopen system. I'll have you do this manually so that you understand everything that's actually happening, then for extra credit, you'll use the c-skeleton skeleton to create it.