krb5 library-building help
raeburn at MIT.EDU
Wed May 4 15:52:03 EDT 2005
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
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
Thanks for any porting help you can give us....
More information about the krbdev