Error while compiling krb 1.5
hartmans at MIT.EDU
Sun Jul 9 21:47:47 EDT 2006
>>>>> "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.
More information about the krbdev