\input texinfo @c -*-texinfo-*- @c @c Note: the above texinfo file must include the "doubleleftarrow" @c definitions added by jcb. @c %**start of header @c guide @setfilename krb5-implement.info @settitle Kerberos V5 Installation Guide @setchapternewpage odd @c chapter begins on next odd page @c @setchapternewpage on @c chapter begins on next page @smallbook @c Format for 7" X 9.25" paper @c %**end of header @paragraphindent 0 @iftex @parskip 6pt plus 6pt @end iftex @include definitions.texinfo @set EDITION b7-1 @finalout @c don't print black warning boxes @titlepage @title @value{PRODUCT} Implementor's Guide @subtitle Release: @value{RELEASE} @subtitle Document Edition: @value{EDITION} @subtitle Last updated: @value{UPDATED} @author @value{COMPANY} @page @vskip 0pt plus 1filll @iftex @include copyright.texinfo @end iftex @end titlepage @menu * Shared Library Theory:: * NetBSD Shared Library Support:: * AIX Shared Library Support:: * Solaris 5.3 Shared Library Support:: * Alpha OSF/1 Shared Library Support:: @end menu @node Top, Introduction, (dir), (dir) @comment node-name, next, previous, up @ifinfo This file contains internal implementor's information for the @value{RELEASE} release of @value{PRODUCT}. @include copyright.texinfo @end ifinfo @c The master menu is updated using emacs19's M-x texinfo-all-menus-update @c function. Don't forget to run M-x texinfo-every-node-update after @c you add a new section or subsection, or after you've rearranged the @c order of sections or subsections. Also, don't forget to add an @node @c comand before each @section or @subsection! All you need to enter @c is: @c @c @node New Section Name @c @section New Section Name @c @c M-x texinfo-every-node-update will take care of calculating the @c node's forward and back pointers. @c @c --------------------------------------------------------------------- @menu * Introduction:: * Shared Libraries:: @end menu @node Introduction, Shared Libraries, Top, Top @chapter Introduction This file contains internal implementor's information for @value{PRODUCT}. It is currently contains information that was removed from install.texi; eventually it will have more detailed information on the internals of the @value{PRODUCT}. @node Shared Libraries, , Introduction, Top @chapter Shared Libraries @menu * Shared Library Theory:: * Operating System Notes for Shared Libraries:: @end menu @node Shared Library Theory, Operating System Notes for Shared Libraries, Shared Libraries, Shared Libraries @section 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. @footnote{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.@footnote{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. @node Operating System Notes for Shared Libraries, , Shared Library Theory, Shared Libraries @section Operating System Notes for Shared Libraries @menu * NetBSD Shared Library Support:: * AIX Shared Library Support:: * Solaris 5.3 Shared Library Support:: * Alpha OSF/1 Shared Library Support:: @end menu @node NetBSD Shared Library Support, AIX Shared Library Support, Operating System Notes for Shared Libraries, Operating System Notes for Shared Libraries @subsection 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. @node AIX Shared Library Support, Solaris 5.3 Shared Library Support, NetBSD Shared Library Support, Operating System Notes for Shared Libraries @subsection 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 @samp{--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 @samp{--enable-shared} is not specified. The AIX 3.2.5 linker dumps core trying to build a shared @samp{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 @samp{libkrb5.a} when GNU C is used. @node Solaris 5.3 Shared Library Support, Alpha OSF/1 Shared Library Support, AIX Shared Library Support, Operating System Notes for Shared Libraries @subsection 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. @node Alpha OSF/1 Shared Library Support, , Solaris 5.3 Shared Library Support, Operating System Notes for Shared Libraries @subsection 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 @samp{-rpath} option to @samp{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 @samp{-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.... @contents @bye