Error while compiling krb 1.5

[Sam Hartman]

>>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:

    Marcus> Sam Hartman <hartmans at mit.edu> writes: ...
    >> Well, I think I've made our position reasonably clear: we're
    >> not spending time on any of this but we're willing to evaluate
    >> designs and patches from others.
    >> 
    >> Let me know if you would like me to better define the
    >> requirements I've sent out.

    Marcus> I agree you sent out quite a bit on requirements already.

    Marcus> That brings us right back around to "agreeing on
    Marcus> semantics".  The reason I proposed specific cases was to
    Marcus> elicit comment and progress here.  The different cases I
    Marcus> proposed would all "solve" the static library problem,
    Marcus> with different semantics, and build consequences.  Some of
    Marcus> those might affect MIT future plans, or others.  So far,
    Marcus> /3/ is easy to hate.  Your requirements express lack of
    Marcus> faith in /2/, but that is what pam does today.

Ah.  I thought you were claiming that we could easily do all three
cases, not that you wanted to explore all three cases.

I think that supporting plugins that can be built in statically is
possible, and something like /2/ is posible.

I'm not at all sure I want to expose all the knobs to the end user.  I
probably only want one knob related to whether shared libraries are
built.  I agree you could expose dynamic plugins separately from
dynamic libraries separately from whether you build the KDC.  I don't
think that is something we're all that thrilled about doing although
I'll listen to arguments.

    Marcus> So let me ask you this: /1/ you say GSS mechs might be
    Marcus> plugins.  Do you have plans or intentions for other
    Marcus> plugins.  Are these only on the kdc machine, or the gss
    Marcus> libraries, or do you expect to be making significant
    Marcus> changes to other parts of the library environment a
    Marcus> vanilla k5 client application might see?

Yes.  I know that 1.6 is likely to have preauth plugins on the client.
It would be possible to get crypto plugins in some future release.

It is likely we will have plugins related to GSS name attributes.

    Marcus> /2/ what systems do you currently support today -- ie,
    Marcus> when you say "portable" - I'll bet you don't mean ebcdic
    Marcus> or 16-bit, but do you include aix 4.3?  sgi irix?  Do you
    Marcus> expect everything to run everywhere (ie, kdc on ms
    Marcus> windows, or both static and shared libraries on aix 3.2
    Marcus> say?)  Also, surely you don't expect your contributors to
    Marcus> have access to exactly the same set of architectures?

AIX is definitely in in terms of shared library support.  The client
libraries run on windows.  The KDCs do not; we do not want to make it
significantly harder to port them though.

We do expect people submitting patches in this area to have
significant access to platforms with interesting shared library
semantics; HP and AIX come to mind.

    Marcus> /3/ it seems to me you've already got the complexity when
    Marcus> you expect initializer routines to work in plugins.  c++
    Marcus> constructors aren't really part of the C language, so you
    Marcus> got mess there.  Shared objects are inherently hairy -
    Marcus> even libtool won't fix that.  Somewhere here you're going
    Marcus> to end up trying to draw a line in the sand.  So perhaps
    Marcus> more importantly, how do you expect people who want to do
    Marcus> more to cope?

I don't understand this question.

--Sam