Linux Programming Hints
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:
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:
#!/bin/sh echo -n > $JUMP_DIR/jump.import for lib in $*; do nm --no-cplus -o $lib | \ grep '__GOT__' | sed 's/__GOT__/_/'\ > $JUMP_DIR/jump.import done
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 Shared.inc 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 JUMP_LIB=libxyz export JUMP_LIB JUMP_DIR=`pwd`/jump 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).
Webinar: 8 Signs You’re Beyond Cron
On Demand NOW
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.View Now!
|diff -u: What's New in Kernel Development||May 06, 2015|
|Chrome-Colored Parakeets||May 05, 2015|
|Mumblehard--Let's End Its Five-Year Reign||May 04, 2015|
|An Easy Way to Pay for Journalism, Music and Everything Else We Like||May 04, 2015|
|When Official Debian Support Ends, Who Will Save You?||May 01, 2015|
|May 2015 Issue of Linux Journal: Cool Projects||May 01, 2015|
- diff -u: What's New in Kernel Development
- Mumblehard--Let's End Its Five-Year Reign
- Chrome-Colored Parakeets
- An Easy Way to Pay for Journalism, Music and Everything Else We Like
- When Official Debian Support Ends, Who Will Save You?
- Ubuntu Ditches Upstart
- DevOps: Better Than the Sum of Its Parts
- "No Reboot" Kernel Patching - And Why You Should Care
- Picking Out the Nouns
- Return of the Mac