krb5 library-building help

[Ken Raeburn]

In the development leading up to 1.4 release, we worked on some thread
safety issues, including the addition of some thread-specific data,
some API issues, and laying some of the ground work for allowing
applications to dynamically load and unload the Kerberos and GSSAPI
libraries without resource leaks.

Unfortunately, while some of the facilities we're using to tackle
these are very common these days, the interfaces vary quite a bit from
system to system, and we could use some porting help for some of the
systems we don't have easily accessible.

These facilities include:
 - shared library initialization and finalization functions

   Rather than require an application to call some new function when
   unloading the library, we're using finalization functions to clean
   up global and thread-specific state that may tie up resources.
   (The initialization function does relatively little work on UNIX
   normally, but on Windows is responsible for creating the mutex
   objects needed by the library.)

   Currently, if the means of supporting this can't be worked out by
   the configure script and isn't in src/config/shlib.conf, the shared
   library build won't work.  I'm planning to add an option to disable
   the missing library finalization support and build libraries
   anyways, they'll just leak resources if they're unloaded.

 - shared library export lists

   We're starting to limit the exported symbols to lists somewhat
   closer to the public functions listed in the installed krb5 and
   GSSAPI headers.  We've defined some lists (still being refined),
   and we've started adding stuff to src/config/shlib.conf and
   src/config/lib.in to cause them to be used on a few platforms.

 - How do we know if the application linked in thread support?

   We use weak references, when available, to try to determine whether
   the application we're linked into has also linked in the pthread
   library or not.  But some systems provide stub functions in libc,
   so we have to figure out what functions to look for on a given
   system.

   If we can't figure it out at run time, as on AIX 4.3 and Tru64 5.1,
   then we'll always link in the pthread support.

We've only tested the support on alpha-osf5.1 (always linking in
pthread library), hppa-hpux10.20 with gcc 2.7 and no thread support,
mips-irix6.5.7, i386-linux-gnu, powerpc-aix4.3.3 (always linking in
pthread library), sparc-sun-solaris2.9 (no export lists).

We'd love to get some nice, clean patches for making things work on
additional platforms, including more recent versions of these
operating systems, and both vendor and GNU compiler tools.

If the facilities provided are generic or simple to test for, I think
we'd most like patches to the configure scripts (mainly aclocal.m4) to
test for them, and patches to other files (src/config/lib.in,
src/include/k5-platform.h, src/include/k5-thread.h, etc) to use them
if they're available.  System-specific changes will work too, in
src/config/shlib.in, keyed on the host type triple.

In the nightly snapshots from our main development trunk, I've updated
the documentation a bit on how we use shared libraries and thread
support and so forth.  Let me know if there's anything else I should
explain.

Thanks for any porting help you can give us....

Ken