Guidelines for writing shared library code

The main advantage of a shared library over an archive library is sharing and the space it saves. These guidelines stress ways to increase sharing while avoiding the disadvantages of a shared library. The guidelines also stress upward compatibility.

We recommend that you read these guidelines once to get a perspective of the concepts involved in building a shared library.

When building a shared library there are a few restrictions involving static linking that should be considered. For example:

• External symbols have fixed addresses. If an external symbol moves, you have to re-link all a.out files that use the library. This restriction applies both to text and data symbols.

  Use of the #hide directive to limit externally visible symbols can help avoid problems in this area. (For more details, see ``Use #hide and #export to limit externally visible symbols''.

• If the library's text changes for one process at run time, it changes for all processes.

• If the library uses a symbol directly, that symbol's run time value (address) must be known when the library is built.

• Imported symbols cannot be referenced directly. Their addresses are not known when you build the library, and they can be different for different processes. You can use imported symbols by adding an indirection through a pointer in the library's data.