Libraries

Libraries

The Difference Between Header Files and Libraries

Header files contain instructions solely for the compiler, whereas libraries contain executable (object or machine) code solely for use when linking a program.

Header Files

Header (include) files are files containing declarations and macros for C programs. Their main purpose is:

to keep function declarations and use consistent across multiple files.
to make standard macros and library function declarations available to user programs without the user having to declare these, and to keep their use consistent.

Header files typically have the extension ".h". The standard header files are located in directory /usr/include. Standard header files are included in C programs with lines such as:

#include <stdio.h>

#include <stdlib.h>
User header files are included in C programs with lines such as:

#include "my_header.h"

To have the compiler search in (nonstandard) directories for header file use the include directory option -I, which may appear several times:

cc options -Imyheaderdir -Ianotherheaderdir
options

/usr/include is searched by default and does not need to be specified.

Libraries

Libraries contain executable (object or machine) code. The linker, which generates the final executable for a program, incorporates this code in the program that it is currently linking.

The linker needs to be told to link libraries and may need to be told where those libraries are to be found. This is usually done on the compile command. Note that this is distinct and different from specifying header files (-I options). The relevant options are -L and -l.

cc options -Lmydir
options -lmine -lm

instructs the linker to search for libraries in directory mydir, as well as, the usual place(s) such as /usr/lib. The libraries to search for are libmine.a or libmine.so as appropriate, as well as, the math library libm.a or libm.so as appropriate (see shared libraries below). Note that a prefix lib and a suffix .a or .so are appended to the name specified on the command line.

The standard C library libc.a or libc.so is automatically linked last and does not need to be specified. The order and location of the -l options is important. Since object and library files given on the command line are examined left to right, libraries should be given last (on the right); code from a library is used only if it resolves references in files examined up to that point in the command line.

Some libraries that may need to be linked in with an -l option are: m (math library), X11 (X 11), pthreads (POSIX threads library), and various networking libraries (for example, xnet on Solaris 2.6 or nsl, socket on older Solaris systems).

Note that the compiler automatically asks the linker to link in a startup routine (as if it had been added as the first argument). Typically crt0.o or something similar is used, but the startup routine may vary. For example, with the debugging option (-g) or profiling options, many compilers will use different startup routines, such as gcrt1.o, mcrt1.0 or what have you.

A simple compile command such as cc hello.c on many systems will result in a linker (loader) command such as ld /lib/crt0.o hello.o -lc which uses library /usr/lib/libc.a.

Static versus Dynamic Libraries

There are two types of libraries, statically linked libraries and shared or dynamically linked libraries. Statically linked libraries are linked into the final executable by the linker. The size of the final code increases by the amount of code the linker needs to insert from the libraries. Dynamically linked libraries are not linked into the executable at link time, although references are resolved; instead at run time the libraries are linked in (by a run time linker).

Dynamically linked libraries are significantly better than static libraries and should be used whenever possible for the following reasons:

Programs share dynamically linked libraries but cannot share statically linked libraries. Since many of the common libraries are probably already loaded on the system, and since many different programs are likely to use common libraries, this will significantly cut down on the memory used (wasted) by a running system. This makes more memory available to users and increases speed by cutting down on paging.
Since the library is not linked into the executable located in the file system, the executable is much smaller. This saves file space and makes the executable faster to load.
Changes to libraries, assuming the change does not involve changing the parameters of library functions, do not necessitate recompilation of the executable. Libraries can be upgraded and bugs can be removed without costly and time consuming recompiles of all client programs. Client programs will run under the latest set of libraries.

Statically compiled programs are appropriate only if there is a security concern about changes to libraries or for executables that need to be runnable even in the event of system problems that prevent libraries from loading. Root's shell is usually statically linked for this reason. Static binaries are often located in directory /sbin.

Static libraries typically have the extension ".a", whereas dynamically linked libraries have extension ".so".

Using Shared Libraries on Solaris

On Solaris systems, the environment variable LD_LIBRARY_PATH specifies the search path for shared libraries. Typically it will contain /usr/openwin/lib and perhaps a compiler and a database library directory. A program can be compiled with option -R (or the variable LD_RUN_PATH can be set) which records in the executable the names of shared library directories to search; this way users do not need to change their LD_LIBRARY_PATH to include new search directories. The Solaris linker searches for libraries in directories given in LD_LIBRARY_PATH (as if these had been given with a -L option).

The system call dlopen( ) can be used by programs that wish to handle libraries directly.

Useful Utilities

ldd - show shared library dependencies
This utility prints the shared libraries required by specified programs. Use it to discover which libraries are needed by a program and perhaps missing on your system.

Generating Shared Libraries

The command used to generate shared libraries varies.
The Solaris C compiler the command is:

cc -G -o libmine.so file1.o ...
Consider using -KPIC to make code position-independent.
The gcc command is:

cc -shared -o libmine.so file1.o ...
where libmine.so is the name of the shared library and the remaining files are the object files to put in the library.

Generating Static Libraries

The command used to generate static libraries is

ar r libmine.a file1.o ...

ranlib libmine.a ## needed on BSD systems only
where libmine.a is the name of the static library. Since these command usually appear in a Makefile and many makes define RANLIB if ranlib is needed, good commands for Makefiles are:

libmine.a: file1.o ...

$(AR) r $@ $?

$(RANLIB) $@
and you would define RANLIB=-@true in your environment (.profile or .login file) for the majority of systems that do not use ranlib.

Last update: 2001 April 28