Building shared libraries for Linux is often considered a black art. In this
article, Eric eXPlains five simple steps to prodUCing a standard Linux shared
library, and tells the curious where to find more information.
by Eric Kasten
Shared libraries are probably most often used because they allow for the creation of shared executables, which take less disk space. They also allow the compression of multiply defined global variables into a single instance of the variable that all program modules share. Also possible is the creation of a compatible, drop-in replacement for an existing shared library. Improvements or fixes in the replacement library are then immediately available to executables the library is linked with. This last possibility is beyond the scope of this article.
Dynamically linked libraries (DLLs) have become an important part of the Linux system. Even though ELF (the executable and linking format designed for Unix SVR4), which makes creating shared libraries trivial, is just over the horizon, the current a.out DLL shared libraries will probably need to be supported for some time. In many cases, older versions of Linux will still need support, and commercial a.out libraries may require that an executable be built using a.out DLLs, because a.out libraries and ELF libraries cannot be mixed in one executable. Until ELF makes its way from the alpha releases of Linux into the more stable releases required for a production environment--and probably even after that--a.out shared libraries will continue to be built and used.
Provided with the source code for a static library, a shared version of the library can be created by completing five well defined steps. This article will explain how to apply these steps to create a simple shared library. Its aim is to help you understand shared libraries and how they are built, so you can successfully create more complicated shared libraries in the future.
Background
This article assumes the use of gcc 2.6.2 and DLL tools 2.16 with libc 4.6.27. Other versions may have slightly different syntax or may operate differently. All these items may be oBTained by anonymous FTP from tsx-11.mit.edu in /pub/linux/packages/GCC/ (tools-2.16.tar.gz is in the src Directory). Follow closely all the installation instructions in the release notes, or unnecessary problems may result.
Shared libraries consist of two basic parts: the stub and the image. The stub library has an extension of .sa. The stub is the library an executable will be linked to. It provides redirection of shared functions and variables to the location where the real shared functions and variables reside in memory. The library image has an extension of .so, followed by a version number.
The library image contains the actual executable functions used by binary programs. The image also contains two tables of particular note: the jump table and the global offset table (GOT). The jump table contains eight-byte entries which redirect a ca ll to a shared function from the jump table to the real function. The jump table exists to provide a method for creating compatible replacement libraries. Since each function has an entry of fixed size in the jump table, the jump table can provide an entr y point for these functions at a location that remains constant between revisions of a library. This allows previously linked executables to continue to function without recompilation. The global offset table functions for global variables as the jump tab le does for library functions.
Each shared library is loaded at a fixed address between 0x60000000 and 0xc0000000. If an executable is linked to two or more shared libraries, the libraries must not occupy the same address range. If two libraries should overlap, the location an executable is redirected to may not contain the expected function or variable. A list of registered shared libraries can be found in the tools 2.16 distribution in the directory doc/table_description. Examine this file when defining the load address for a new shared library to ensure that it doesn't conflict with the address for an existing library. In addition, you should probably register the address space used by a new shared library so that future libraries will not conflict with it. Registration is particularly important if the library is to be distributed.
Before Beginning
As mentioned earlier, this procedure is directed at the creation of a simple shared library. Although the steps for building a more complex library are the same, the process of modifying multiple or complex makefiles can become somewhat confusing. For your first attempt it is a good idea to select a library which has all the library source in a single directory. A good choice may be the JPEG library, which can be retrieved by anonymous FTP from ftp.funet.fi with file name /pub/gnu/Ghostscript3/jpegsrc.v5.tar.gzi. Or you could create several simple source code modules and a makefile to compile and build a static library. This test library need not do anything useful, since it is only for educational purposes. However, since you will already understand the inner workings of the build process, you can avoid the effort of attempting to understand another programs makefile logic. Also, be sure that a static version of the library can be successfully compiled before approaching the construction of a shared one.
Step One: Setup
The method presented here is not the only way to create a shared library, but it has often proved successful. It provides, in the form of a file to include in the makefile, a simple record of the parameters and the method used to build a particular library. First, create the file that will be included in the makefile; call it Shared.inc. The file should look something like:
SL_NAME=libxyz
SL_PATH=/usr/local/lib
SL_VERSION=1.0.0
SL_LOAD_ADDRESS=0x6a380000
SL_JUMP_TABLE_SIZE=1024
SL_GOT_SIZE=1024
SL_IMPORT=/usr/lib/libc.sa
SL_EXTRA_LIBS=/usr/lib/gcc-lib/i486-linux\
/2.6.2/libgcc.a -lc
SHPARMS=-l$(SL_PATH)/$(SL_NAME)\
-v$(SL_VERSION) \
-a$(SL_LOAD_ADDRESS) \
-j$(SL_JUMP_TABLE_SIZE) \
-g$(SL_GOT_SIZE)
VERIFYPARMS=-l$(SL_NAME).so.$(SL_VERSION) -- \
$(SL_NAME).sa
CC=gcc -B/usr/bin/jump
pre-shlib: $(LIBOBJECTS)
shlib-import:
buildimport $(SL_IMPORT)
shlib: $(LIBOBJECTS)
mkimage $(SHPARMS) -- $(LIBOBJECTS) $(SL_EXTRA_LIBS)
mkstubs $(SHPARMS) -- $(SL_NAME)
verify-shlib $(VERIFYPARMS)
The first section consists of a series of variable definitions. These variables have the following meanings:
SL_NAME
The name of the library which is being built.
SL_PATH
The location where the shared library will live.
SL_VERSION
The library version.
SL_LOAD_ADDRESS
The absolute address in memory where the library will be loaded. (Examine the table_description file provided with the DLL tools to make sure this address doesn't overlap with another library).
SL_JUMP_TABLE_SIZE
The size of the jump table. (Give this any value for the moment; an appropriate value will be determined later).
SL_GOT_SIZE
The size of the global offset table. (Give this any value for the moment; an appropriate value will be determined later).
SL_EXTRA_LIBS
Other libraries which are required to build the shared image.
SL_IMPORT indicates other shared libraries to import symbols from. These imported symbols are used to help direct global variable references to their proper locations in other sha
