     [file definitions.texinfo not included]

This file contains internal implementor's information for the RELEASE release of PRODUCT.

     [file copyright.texinfo not included]

Introduction
************

This file contains internal implementor's information for PRODUCT.  It is currently contains information that was removed from install.texi; eventually it will have more detailed information on the internals of the PRODUCT.

Shared Libraries
****************

Theory of How Shared Libraries are Used
=======================================

An explanation of how shared libraries are implemented on a given platform is too broad a topic for this manual. Instead this will touch on some of the issues that the Kerberos V5 tree uses to support version numbering and alternate install locations.

Normally when one builds a shared library and then links with it, the name of the shared library is stored in the object (i.e. libfoo.so). Most operating systems allows one to change name that is referenced and we have done so, placing the version number into the shared library (i.e. libfoo.so.0.1). At link time, one would reference libfoo.so, but when one executes the program, the shared library loader would then look for the shared library with the alternate name.  Hence multiple versions of shared libraries may be supported relatively easily.  (Under AIX for the RISC/6000, multiple versions of shared libraries are supported by combining two or more versions of the shared library into one file.  The Kerberos build procedure produces shared libraries with version numbers in the internal module names, so that the shared libraries are compatible with this scheme. Unfortunately, combining two shared libraries requires internal knowledge of the AIX shared library system beyond the scope of this document.  Practicallyspeaking, only one version of AIX shared libraries can be supported on a system, unless the multi-version library is constructed by a programmer familiar with the AIX internals.)

All operating systems (that we have seen) provide a means for programs to specify the location of shared libraries. On different operating systems, this is either specified when creating the shared library, and link time, or both. (Both are necessary sometimes as the shared libraries are dependent on other shared libraries) The build process will hardwire a path to the installed destination.

Operating System Notes for Shared Libraries
===========================================

NetBSD Shared Library Support
-----------------------------

Shared library support has been tested under NetBSD 1.0A using GCC 2.4.5. Due to the vagaries of the loader in the operating system, the library load path needs to be specified in building libraries and in linking with them. Unless the library is placed in a standard location to search for libraries, this may make it difficult for developers to work with the shared libraries.

AIX Shared Library Support
--------------------------

AIX specifies shared library versions by combining multiple versions into a single file.  Because of the complexity of this process, no automatic procedure for building multi-versioned shared libraries is provided. Therefore, supporting multiple versions of the Kerberos shared libraries under AIX will require significant work on the part of a programmer famiiliar with AIX internals.

AIX allows a single library to be used both as a static library and as a shared library.  For this reason, the --enable-shared switch to configure builds only shared libraries.  On other operating systems, both shared and static libraries are built when this switch is specified.  As with all other operating systems, only non-shared static libraries are built when --enable-shared is not specified.

The AIX 3.2.5 linker dumps core trying to build a shared libkrb5.a produced with the GNU C compiler.  The native AIX compiler works fine.  In addition, the AIX 4.1 linker is able to build a shared libkrb5.a when GNU C is used.

Solaris 5.3 Shared Library Support
----------------------------------

Shared library support only works when using the Sunsoft C compiler. We are currently using version 3.0.1.

The path to the shared library must be specified at link time as well as when creating libraries.

Alpha OSF/1 Shared Library Support
----------------------------------

Shared library support has been tested with V2.1 and higher of the operating system. Shared libraries may be compiled both with GCC and the native compiler.

One of the nice features on this platform is that the paths to the shared libraries is specified in the library itself without requiring that one specify the same at link time.

We are using the -rpath option to ld to place the library load path into the executables. The one disadvantage of this is during testing where we want to make sure that we are using the build tree instead of a possibly installed library. The loader uses the contents of -rpath before LD_LIBRARY_PATH so we must specify a dummy _RLD_ROOT and complete LD_LIBRARY_PATH in our tests.

The one disadvantage with the method we are using....