1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
\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
|
