Error while compiling krb 1.5

[Sam Hartman]

>>>>> "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
    Russ> plugins.
    >>  Except that it is likely that GSS mechs will be plugins in
    >> 1.6.

    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
    Donn> plugins.


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
optimistic.

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.

--Sam