Linux Programming Hints

Building shared libraries for Linux is often considered a black art. In this article, Eric explains five simple steps to producting a standard Linux shared library and tells the cuious where to find more information
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 The file should look something like:

        /2.6.2/libgcc.a -lc
        -v$(SL_VERSION) \
        -a$(SL_LOAD_ADDRESS) \
        -j$(SL_JUMP_TABLE_SIZE) \
CC=gcc -B/usr/bin/jump
pre-shlib: $(LIBOBJECTS)
        buildimport $(SL_IMPORT)
shlib:  $(LIBOBJECTS)
        mkimage $(SHPARMS) -- $(LIBOBJECTS)
        mkstubs $(SHPARMS) -- $(SL_NAME)
        verify-shlib $(VERIFYPARMS)

The first section consists of a series of variable definitions. These variables have the following meanings:


The name of the library which is being built.


The location where the shared library will live.


The library version.


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).


The size of the jump table. (Give this any value for the moment; an appropriate value will be determined later).


The size of the global offset table. (Give this any value for the moment; an appropriate value will be determined later).


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 shared libraries. The libraries specified here should be any shared libraries which are required to build the target library. The target shlib-import makes use of a /bin/sh script called buildimport, which is invoked with SL_IMPORT as a parameter. The build import script should contain the following commands:

echo -n > $JUMP_DIR/jump.import
for lib in $*;
  do nm --no-cplus -o $lib | \
     grep '__GOT__' | sed 's/__GOT__/_/'\
      > $JUMP_DIR/jump.import

This script uses nm, grep and sed to extract the symbols from the global offset tables of each of the stub libraries specified on the command line to create a file called jump.import (the nm command sequence is excerpted from “Using DLL Tools With Linux”). Be sure to chmod u+x buildimport. SL_EXTRA_LIBS are libraries which will be required to successfully build the library. Usually most of these libraries can be determined by examining a makefile which builds an executable using this library (often there are test programs included with the source for the library). libgcc.a is required with gcc 2.6.2; if it is left out, there will be an unresolved reference for _main. It is usually necessary to explicitly specify libc with -lc. If there should be unresolved references when the library image is made, chances are that a required library was omitted.

The definition of CC as gcc -B/usr/bin/jump is telling the compiler to use an assembler called /usr/bin/jumpas instead of the default assembler. Be sure to check what other parameters are specified in the original makefile (and whether CC was defined as the compiler variable) and make additions and changes as necessary. CC is nearly always defined, and thus has been used in this example. If you use a version of DLL tools earlier than version 2.16, it may be necessary to specify CC as gcc -B/usr/dll/jump/.

The targets pre-shlib and shlib both have LIBOBJECTS as dependencies. You will probably find a list or a variable containing a list of the library dependencies in the target for the static library in the original makefile. You should define LIBOBJECTS as this list of dependencies, or you should replace all instances in with the dependencies specified for the static library. Take care when constructing a dependency list for a shared library; it is not uncommon for source code modules to be compiled even though they are not part of the final library. The only objects that should be compiled during the building of a shared library are those that will eventually become part of the library. If other objects are compiled, the symbols and globals used in those modules will end up in the jump configuration files for the library, and possibly in the library itself. These undesirable functions and variables may result in troublesome behavior or failure of the library build process.

In general, make sure you understand how the library object files are built. Also, make certain that the shared library objects are built using the same flags and options that were present for the original library. Now edit the library makefile (make a backup first), and add the following statement to the end of the list of makefile targets:


Finally, from the source directory of the library, do the following:

 mkdir jump
 export JUMP_LIB
 export JUMP_DIR

These commands create a work directory for the DLL tools and assembler, and set the necessary environment variables which are required to successfully build a shared library. It will be necessary to use setenv if a csh variant is in use. Remember to replace libxyz with the name of the target library (as specified in SL_NAME).



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Anonymous's picture


One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix