> There must be some valid reasons to remove the static library  
> compilation
> from latest MIT krb5 source code.

Yes: It was a pain to maintain the ability to compile libraries in  
multiple modes, and deal with platforms like AIX  where you don't  
actually distinguish between them based on library suffix.  Also,  
we've added a plugin architecture that wants to be able to  
dynamically load code that may depend on the Kerberos library or (for  
internally built modules) internal libraries, and thus would need the  
shared Kerberos library anyways.  So now internal libraries that

These are not necessarily insurmountable problems, but most of the  
approaches we've considered are either not trivial to implement or  
raise issues that need some serious consideration (or both).  For  
example, statically linking in a bunch of "plugins" for the static  
build means resolving name conflicts across all plugins we ship.   
Some of the plugin interfaces currently work by providing one or more  
dynamic object files in directory X that define symbol Y; that would  
have to change, at least for the static mode.  Removing dependencies  
of dynamic plugins on the Kerberos libraries (that would no longer be  
available dynamically) may be possible, by explicitly passing to the  
plugin a structure holding function pointers for everything it could  
possibly want, but it's ugly, and we don't have a good list of  
symbols for that right now.  (We have an export list used for  
building shared libraries on Windows and Mac; it may or may not be  
enough for plugins, but we know it's not enough to implement our own  
KDC.  We have another export list we use on UNIX, which is basically  
everything including a bunch of private internal APIs you shouldn't  
touch, and it will eventually get trimmed down; initially it was just  
a placeholder so we could implement the *use* of the export list on  
various UNIX platforms, and then worry about what the right export  
list was later.)

You may be able to hack the configure scripts and Makefiles into  
generating static libraries that can't load some plugins, and  
building a KDC that won't work, etc., which may be enough for you.   
We're probably not going to give you support for that kind of build  
process though.

If you or someone else wants to dig into the issues around restoring  
static builds -- I suspect the plugin handling is the biggest part of  
it, but I'd also like to see a more general way of extending the  
build process to multiple suffixes for object files, multiple  
libraries, etc -- I'd be happy to try to give some feedback, but for  
most of the "customer" base I think shared-only libraries work well  
enough (based on feedback or at least lack of complaints, from end  
users, system integrators, Kerberos Consortium members, etc), so it  
hasn't been a priority for us to put effort into this currently,  
relative to other projects in the works....

Ken