A SharedLibrary contains subroutines that can be linked to a BinaryExecutable at RunTime. This allows for sharing code between applications, which has a number of advantages:

• It saves on disk space, since functions common to many programs don't need to exist in identical copies in each of their binaries.
• It saves on memory for the same reason -- you only need a single copy of the SharedLibrary in memory. This also means that the memory footprint columns in ps(1) never add up correctly.
• Fixing a bug in the shared code automatically fixes that bug for all programs that use the library, without actually having to touch these programs.
• Likewise, performance or other improvements are automatically propagated to every program using a library.

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

libext2fs.so.2 => /lib/libext2fs.so.2 (0x40023000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x40037000) libe2p.so.2 => /lib/libe2p.so.2 (0x40039000) libuuid.so.1 => /lib/libuuid.so.1 (0x4003e000) libc.so.6 => /lib/libc.so.6 (0x40041000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (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

/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,libfoo.so -o libfoo.so.1.0.1 foo.c bar.c baz.c -lquux

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

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 environment variable.

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 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 Linux/gcc uses -shared, -fPIC, -soname for certain options, Solaris 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.la 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 LDLIBS env var 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 libtrace.la /usr/local/wand/lib/libtrace.la 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

nm /lib/libc.so.6

doesn't work, as libc is a dynamic library, however

nm --dynamic /lib/libc.so.6

will. just FYI.

Good external resources

• Ulrich Drepper's How to write shared libraries.
• Mike Hearn's Writing shared libraries.
• (can't anyone come up with a unique descriptive name for this stuff?)