Error while compiling krb 1.5
hartmans at MIT.EDU
Wed Jul 5 18:57:07 EDT 2006
>>>>> "Donn" == Donn Cave <donn at u.washington.edu> writes:
Donn> On Jul 5, 2006, at 12:58 PM, Sam Hartman wrote:
>>>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:
Russ> My guess is that most people's static build requirements
Russ> would be satisfied by a build option that builds both static
Russ> and shared libraries, still builds all the server code (kdc,
Russ> kadmind, etc.) against the shared libraries, and only builds
Russ> the clients against the static libraries. That makes the
Russ> build machinery more complex, but it sould resolve the
Russ> plugin problem since I don't expect the clients will need
>> Except that it is likely that GSS mechs will be plugins in
Donn> In this case, going back to your question,
>> * what does it mean to build static? The easiest semantic is
>> that you build everything static except that the plugins are
>> still shared.
Donn> ... I will be wanting an option where the plugins are not
Donn> shared. Of course that means they aren't really plugins,
Donn> which is fine. For the same reasons as with shared
Donn> libraries in general, I don't want applications to depend on
MIt has no interest in working on such a solution although we aren't
inherently apposed to accepting such a patch. We don't expect it is
possible to meet our requirements in this area so we're not real
We're also interested in feedback from people who ship Kerberos in a
product or operating system that have issues with the approach we're
taking. I think Ken Hornstein' situation i s close enough to product
to count, although obviously we've received his feedback.
Here are our requirements:
* Must not decrease the portability of our code base. I.E. we need to believe that this interface will not require tweaking for new platforms.
* Must not increase the build system complexity. It can move
complexity around but we need to believe that things are not more
complex than they are today when all is done.
* Must not increase complexity of writing plugins for third parties or
complexity of adding plugin interfaces to MIT Kerberos.
* Must not increase the complexity of referencing symbols from the
base Kerberos library in plugin code either for third parties or for our distribution.
* Must support calling library initializer routines in plugins even
when they are built in statically.
* Must work with the existing plugin API. IN particular, needs to
support plugins like GSS where you have a lot of functional entry
points and plugins like the DAL and location plugin where you look
up one struct. This interface needs to be supported from the
standpoint of the rest of the kerberos code base. Something close
to this interface needs to be support from the plugin side. A
header file of symbol renames might be OK, but a bunch of macros
around definitions and declarations probably would not.
We're probably willing to live with making sure that non-exported
symbols from one plugin in our tree do not clash with other plugins.
This is probably not currently true.
More information about the krbdev