Error while compiling krb 1.5

[Ken Raeburn]

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

Currently we support one other kind in non-KDC programs, for service  
location.  The krb5 library will look for plugins defining routines  
that can be called to find the KDCs of a realm, or the password- 
changing service, or krb524, etc.  This was desired by some of the  
Samba folks.  Offhand I'm not sure what else we'll be adding down the  
road for non-KDC systems.

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

We've got a small list of platforms we're doing local testing on at  
the moment.  Our AIX (4.3.3) machine recently died; the ia64-linux  
box we were testing on belongs to another group and is currently off;  
our IRIX box (6.5.something-old) has recently been reinstalled and  
hasn't had our automated test setup re-established yet, and it's not  
running the current OS anyways; our alpha-linux box recently had disk  
problems, and I haven't had time to open it up and see about fixing  
them or swapping out the disk.  So MIT's list of actually-tested  
platforms has shrunk a little recently.  Our main testing platforms  
for the UNIX release are Solaris 9/10 on SPARC, and Red Hat and  
Debian GNU/Linux on x86.  I don't want to put words in Sam's mouth,  
but I personally think it would be good to expand our porting and  
testing if it doesn't add much of a workload.  (I'm doing a little  
outside work on ports to other systems, in my spare time, but it's  
not part of my work for MIT.)

We have what might generously be called an automatic testing  
framework, that does test builds on various configurations every  
night.  It's kind of clunky, and collecting results relies on me  
having access to each machine and running some commands by hand, so  
adding random additional outside systems isn't easy, even if someone  
was willing to just run whatever random commands we put in our  
configure scripts and makefiles every night.

We don't currently build or test the KDC-side programs on Windows,  
and we are already aware of various problems (like DLL export lists)  
that will cause difficulties there.  Everything else "should" work on  
most reasonably modern UNIX/POSIX systems, but we know there will be  
porting issues like the specific implementation details for #3  
below.  On the Mac ... well, we've had some interesting discussions  
trying to figure out how to manage things there, and I expect we'll  
have some more, but Alexis always manages to beat the KfM release  
into decent shape.

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

It's not part of C, no, but practically every modern-enough system  
supports C++.  If it supports destroying static-storage objects when  
a library using C++ is unloaded, then the linker or compiler or both  
must have support for the functionality; the trick is getting access  
to it from C.  (On systems with POSIX threads, we generally delay the  
initialization and use pthread_once rather than library load-time  
initialization, so it's just unloading where we really need this  
support.)  So far -- and I readily acknowledge that our limited list  
of test systems is a problem here -- it appears that every system we  
care about does have the support, through compiler options or linker  
command-line options or special function names.

It could be argued that if they don't support destroying objects on  
unload, then they don't support C++ very well, and everybody wants to  
provide C++ support....


Actually, a bit that concerns me more is the ability to build  
libraries that can be used with or without linking in POSIX thread  
support.  On most platforms we can use weak symbol references and  
check and see at run time if the functions are there (and if they're  
found, whether they actually work or they're broken stub functions  
like we've encountered before).  Recently it's occurred to me that it  
might not work in certain cases involving dlopen, but I haven't had  
time to investigate....

Ken