[krbdev.mit.edu #5935] Kerberos static library compilation

[sharma via RT]

Hi Ken

Thanks for prompt reply.

I think the middle approach like generating all the dynamic libraries that
are generated right now and also bundle the respective object files into a
static library may solve our problem. I am not talking about a separate
static and dynamic build as supported in krb5 1.5.x series.

I may be able to hack into the Makefile.in and configure script files,
forward the changes to you. My main concern is to incorporate the changes
into Kerberos source code repository so that we do not have to do the
changes every time the new Kerberos version is released.

Also I am using MIT Kerberos libraries on the following platforms to build
our application, and hopefully cover most of the system in use.

1. Windows x86:   32 bit mode, VC 2005 compiler
2. Linux x86/x64: 32/64 bit mode, gcc compiler (x86 and AMD 64 systems
running fedora and red hat linux)
3. Solaris x86/x64: 32/64 bit mode, gcc compiler (x86 and AMD 64 systems
running Solaris 8 and 10)
4. Solaris Sparc: 32/64 bit mode, gcc compiler (Solaris Sparc system running
Solaris 8)
5. HP-UX: 32/64 bit mode, gcc compiler (HP system running HP-UX 11, I think)
6. AIX: 32/64 bit mode, gcc compiler (IBM system running AIX 5.2)
7. SGI: 32/64 bit mode, gcc compiler (SGI system running IRIX 6.5)
8. MAC PPC: 32 bit mode, gcc compiler (APPLE system running MAC OSX 10.4)
9. MAC X86: 32/64 bit mode, gcc compiler (APPLE system running MAC OSX 10.4)

We plan to compile our application and kerberos code in 32 and 64 bit mode
for all platforms possible and we are almost there.

SAM SHARMA

-----Original Message-----
From: 0000-Admin [mailto:daemon at MIT.EDU] On Behalf Of Ken Raeburn via RT
Sent: Wednesday, April 02, 2008 12:14 PM
To: sam.sharma at gat.com
Subject: Re: [krbdev.mit.edu #5935] Kerberos static library compilation

> 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