Examining SharedLibrary dependencies on Unix

On many Unix systems, you can use the ldd(1) command to see which shared libraries a program is linked against:

$ ldd /sbin/mke2fs => /lib/ (0x40023000) => /lib/ (0x40037000) => /lib/ (0x40039000) => /lib/ (0x4003e000) => /lib/ (0x40041000)
       /lib/ => /lib/ (0x40000000)

Trying this on a statically linked program:

$ ldd /sbin/init
       not a dynamic executable

On Darwin, the corresponding program is called otool:

$ otool -L /bin/zsh
       /usr/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)
       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 60.0.0)

Creating a SharedLibrary

Assuming the source is in the files foo.c, bar.c, baz.c, you call GCC like so:

gcc -shared -Wl,-soname, -o foo.c bar.c baz.c -lquux

This creates a SharedLibrary file, with shared object name ("soname"), dependent on libquux. To make libfoo usable, you need to put it someplace ldconfig(8) will find it, and SymLink it to and

So long as you don't change the call signature of one of the functions (or what they do, in a way that would break programs), you can just bump the minor version of the library and programs using the SharedLibrary will just work. If you do change call signatures on existing functions or change their semantics, bump the version, try to recompile the programs, and check that they work correctly once they pass. Another way to make it usable is to put it in a directory refered to in your LD_LIBRARY_PATH EnvironmentVariable.

You may wish to use -Wl,-O1 when linking too, it will optimise the hashtables used for symbol lookup making the startup time faster.

Creating static shared libraries

In some cases you may not want your shared library to have any extra dependencies. In such a case you want your shared library to have its dependencies statically linked in. Even a simple shared library will have a couple of dependences:

ldd ./ => /lib/ (0x0000002a95675000)
        /lib64/ (0x000000552aaaa000)

The obvious way to statically link these dependencies would be:

gcc -shared -static -o sam.c

This will either not work, or give an error message like:

gcc: -shared and -static|pie|fPIE|fpie|fno-PIC|fno-pic|nopie are incompatible

However, it is possible to directly tell the linker we want static linking, and then magic will happen:

gcc -shared -Wl,-static -o sam.c

ldd ./
        statically linked is still a valid shared library, it just lacks any external dependency. In some cases you might need the command-line option -static-libgcc for this to work.

Creating a SharedLibrary using libtool(1)

libtool(1) is a package designed to assist with the creation of shared libraries. See the libtool(1) node for more information (eventually) about this program

One of the advantages of libtool is that it will use the correct linker options on different platforms, instead of you having to learn them all and putting them in your MakeFile/configure script. (For example GCC uses </tt>-shared</tt>, -fPIC, -soname for certain options, Solaris's CC uses -G, -KPIC, and -h respectively for those same options).

If you have a .c file you wish to include in a library with libtool, you need to make a .lo file for it:

libtool --mode=compile gcc -c trace.c -o libtrace.lo

Once you have a .lo file, you need to make a .la file

LDLIBS=-lpcap -lz
libtool --mode=link gcc -o libtrace.lo -rpath /usr/local/wand/lib \
       $(LDLIBS) \
       -version-info 1:2:0

One nice feature of libtool is that you can specify other shared libraries that this one will depend upon (in the LD_LIBS EnvironmentVariable above), and this will be included in the linker script -- any package linking against libtrace in the above example will automatically link against libpcap and libz as well.

To install the libraries, you use libtool once more:

libtool --mode=install install -c /usr/local/wand/lib/
libtool --finish /usr/local/wand/lib/

As a final step, I make sure to install my header files somewhere useful!

cp ../include/libtrace.h /usr/local/wand/include/libtrace.h

There are excellent docs on using libtool supplied with the program.

Examining symbols in a shared library

Using nm(1) on dynamic libraries requires the --dynamic option:

nm /lib/            # doesn't work
nm --dynamic /lib/  # does work

Help, I moved my library directory and now nothing runs!

A misplaced / led me to moving everything from / to '/etc/old' - when you can't find the library loader, you can't even run bash builtins. Get around it like so:

/etc/old/lib/ /etc/old/bin/mv /etc/old/bin /

See also