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).
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- July 2016 Issue of Linux Journal
- Tibbo Technology's Tibbo Project System
- Client-Side Performance
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Peppermint 7 Released
- Profiles and RC Files
- The Giant Zero, Part 0.x
- Snappy Moves to New Platforms
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide