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 Two: The First Compile

Before each compile remove the old .o files to ensure that the object code is rebuilt. Executing a make clean may be sufficient; however, be careful-many makefiles will remove more than the .o files and you may need to reconfigure the source code. Often an rm *.o will work more dependably.

If everything has been set up properly, it should now be possible to begin the first compile by entering:

 make pre-shlib

This step compiles the library using the assembler prefixed by the -B switch. This will extract the necessary symbols from the library source into a file called jump.log. From jump.log, the global variables and functions will be extracted into the necessary configuration files where the DLL tools will find them. Once all the source has been compiled, change to the directory that was specified in JUMP_DIR. Jump.log should be in this directory. Now execute the following:

 getvars
 getfuncs
 rm -f jump.log

These commands will create the files jump.vars and jump.funcs. jump.vars contains a list of the global variables found during the compile, while jump.funcs contains a list of functions. If, for some reason, you don't want to export a symbol found in jump.funcs or jump.vars, move the entry to a file called jump.ignore in the JUMP_DIR directory. Be sure to remove any entries added to jump.ignore from the original file. Now return to the compile directory.

Step Three: Importing Symbols

Now you should create the jump.imports file. Since a target was previously defined in Shared.inc, simply enter:

 make shlib-import

There now should be a file called jump.imports in the JUMP_DIR directory. Nothing needs to be done with this file; it will be used to determine which global variables should be located in one of the imported libraries.

Step Four: The Second Compile

The second compile is necessary to determine the sizes of the global variables. The sizes of the globals must be known so that the GOT pointers can be set properly. Remove the .o files from the previous compile and then do the following:

 make pre-shlib

Now change to the JUMP_DIR directory and execute:

 getsize > jump.vars-new
 mv jump.vars jump.vars-old
 mv jump.vars-new jump.vars
Step Five: Building The Library

Before actually building the shared image and stub libraries, the jump table and GOT must be allocated enough storage for all the existing functions and global variables as well as for functions or globals that may be added in revisions to the library. To determine the required number of bytes for the jump table and the GOT, execute the following:

 wc -l $JUMP_DIR/jump.funcs
 wc -l $JUMP_DIR/jump.vars

Multiply the resultant line counts by 8 to calculate a lower bound for the number of bytes required for existing functions and global variables, respectively. These values should be padded significantly to allow for future library expansion. Now edit Shared.inc and replace the settings of SL_JUMP_TABLE_SIZE and SL_GOT_SIZE with the values just determined. If you receive an overflow message while building the image, increase these values. Keep in mind that these sizes should be multiples of 8, and that the values calculated are minimums, and will probably not be sufficient to build the library image.

Now everything should be ready to actually build the shared image and stub. Without removing the .o files, execute:

 make shlib

This will first build the image, and then the stub library. Then the stub and image will be verified to check that the libraries were built properly. If all goes well, the last message should be something like:

Used address range 0x6a37f020-0x6a395020 be aware! must be unique! The
stub library and the sharable libraries have identical symbols.

The address range indicated in the first line is somewhat misleading, since a load address of 0x6a380000, not 0x6a37f020, was specified. This is normal. However, make note of the last address since it indicates the last address used by the library. This address is usually padded somewhat to make sure that room is left for expansion. The address range might be recorded as 0x6a380000-0x6a395fff or 0x6a380000-0x6a39ffff, depending on how much space might be required in the future.

The second line indicates that the image and stub libraries were built correctly. If the verification process should indicate that the stub and image differ, an error has occurred. Possibly one of the most common errors is when the JUMP_LIB environment variable and SL_NAME don't match. Double check that these two variables match if there should be a problem. If everything has gone correctly there should now be a stub and image library. The image should be copied to the directory specified by SL_PATH and the stub should be placed where it can be found by the compiler and linker. Once these files have been copied to their final directories, enter:

 ldconfig -v

There should be output similar to the following, indicating that ldconfig has created a symbolic link for the new library in which the name only contains the major version number. This is done because a look-up on the library is done using only the major version number.

 libxyz.so.1 => libxyz.so.1.0.0 (changed)

If ldconfig doesn't find the library, make sure that the directory in which the library is located is included in the list in /etc/ld.so.conf. It should now be possible to make use of the new library. Shared.inc, jump.vars, jump.funcs, jump.import and jump.ignore should be saved. These files will be useful if you need to rebuild the library or create a compatible replacement.

______________________

Comments

Comment viewing options

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

hgf

Anonymous's picture

good

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState