Shared libraries

The building process

To build a shared library the following six steps must be completed:

Step 1: choosing region addresses

Choose region addresses for your shared library.

Shared library regions on the 386-based computer correspond to memory management unit (MMU) segment sizes, each of which is 4 MB. The following table gives a list of the segment assignments on the 386-based computer (as of the copyright date for this guide) and shows what virtual addresses are available for libraries.

Start   Target
Address Contents Pathname
0xA0000000 Reserved for AT&T  
. Shared C Library /shlib/libc_s
. AT&T Networking Library /shlib/libnsl_s
0xA4000000 Generic Database Library Unassigned
0xA5000000 Generic Statistical Library Unassigned
0xA6000000 Generic User Interface Library Unassigned
0xA7000000 Generic Screen Handling Library Unassigned
0xA8000000 Generic Graphics Library Unassigned
0xA9000000 Generic Networking Library Unassigned
0xAA000000 Scan Code library /shilb/libsc_s
0xAB000000 Libprot library /shlib/protlib_s
0xB0000000 For private use Unassigned

If a shared library is built within a reserved address region, there is a risk of conflicting with future products.

A number of segments are allocated for shared libraries that provide various services such as graphics, database access, and so on. These categories are intended to reduce the chance of address conflicts among commercially available libraries. Although two libraries of the same type may conflict, that does not matter. A single process should not usually need to use two shared libraries of the same type. If the need arises, a program can use one shared library and one non-shared library instead.

NOTE: Any number of libraries can use the same virtual addresses, even on the same machine. Conflicts occur only within a single process, not among separate processes. Thus two shared libraries can have the same region addresses without causing problems, as long as a single a.out file does not need to use both libraries.

Several segments are reserved for private use. If you are building a large system with many a.out files and processes, shared libraries might improve its performance. As long as you do not intend to release the shared libraries as separate products, you should use the private region addresses. You can put your shared libraries into these segments and avoid conflicting with commercial shared libraries. You should also use these segments when you will own all the a.out files that access your shared library. Don't risk address conflicts.

NOTE: If you plan to build a commercial shared library, you are strongly encouraged to provide a compatible, relocatable archive as well.

Step 2: choosing the target library pathname

After selecting the region addresses, choose the pathname for the target library. For example /shlib/libc_s was chosen for the shared C library and /shlib/libnsl_s for the networking library. To choose a pathname for your shared library, consult the established list of names for your computer or see your system administrator.

NOTE: Shared libraries required to boot a UNIX system should be located in /shlib; other application libraries normally reside in /usr/lib or in private application directories.

Step 3: selecting library contents

The most important task in the building process is selecting the contents for the shared library. Some routines are prime candidates for sharing; others are not. For example, it is a good idea to include large, frequently used routines in a shared library but to exclude smaller routines that are not used as much. For general guidelines see ``Choosing library members''. See also the guidelines in ``Importing symbols'', ``Referencing symbols in a shared library from another shared library'', and ``Tuning the shared library code''.

Step 4: rewriting existing library code

If you choose to include some existing code from an archive library in a shared library, changing some of the code will make the shared code easier to maintain. See ``Changing existing code for the shared library''.

Step 5: writing the library specification file

After you select and edit all the code for your shared library, you have to build the shared library specification file. The library specification file contains all the information that mkshlib needs to build both the host and target libraries. See ``Writing the specification file'' for a sample specification file. Also, see ``Using the specification file for compatibility''. The contents and format of the specification file are given by the directives list. For a description of each directive, see mkshlib(CP). References to these directives are made throughout this chapter. Prior review of mkshlib(CP) is recommended.

Step 6: using mkshlib to build the host and target

The mkshlib(CP) command builds both the host and target libraries. mkshlib invokes other tools such as the assembler, as(CP), and link editor, ld(CP). Tools are invoked through the use of execvp (see exec(S)), which searches directories in a user's $PATH environment variable. Also, prefixes to mkshlib are parsed in much the same manner as prefixes to the cc(CP) command and invoked tools are given the prefix, where appropriate. For example, 3mkshlib invokes 3ld.

Next topic: Guidelines for writing shared library code
Previous topic: Building a shared library

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003