krb5 thread support and excess support libraries -- seeking opinions, options

[Ken Raeburn]

As previously mentioned, the support for thread-specific data is going
to require some additional code, too much to hide in big macros or
inline functions.  It's also going to require some global storage.

Sam and Tom and I talked about where to put this code.  So far, we
don't have any good solutions.  If anyone can suggest a point out pros
and cons we've overlooked, or other options we didn't consider, we'd
be grateful.

None of the existing libraries is really ideal to put one copy of the
code, to be used by other libraries.  It's needed by the com_err
library, and we can't make libcom_err depend on one of the
higher-level libraries, that also depends on libcom_err.  The com_err
library also isn't an especially appropriate place for it, in terms of
functionality.  And we're supporting the use of a native libcom_err,
so we can't rely on ours being the one to be built.

If we simply duplicate the code in each library that needs it, we're
going to get name conflicts.  Changing the symbol names for each
library means recompiling the code multiple times with different
options, or different tweaks to the source, or something like that.
Sam was pretty strongly opposed to solution, though I'm inclined to
think it's the least ugly of the options we've come up with.

So the path we're trying right now is to add yet another library, for
support code "below" the other libraries.  (Kind of like Heimdal's
libroken, I think.)  Any other library or program which uses this
stuff gets linked against it.  Since the com_err library is one such,
and since we still support static linking, that means pretty much
every program we build uses it indirectly, and any applications based
on our code.  If anyone isn't using the krb5-config script now, this
change is likely to hurt them, if we keep it.

It gets tempting to use something like GNU libtool, but last time we
looked at it, it was much slower than putting the relevant compile and
link commands directly in the makefile, and it didn't support some
things we're doing now, like shared library export lists and
initialization and termination functions.


Since we're looking at a new support library, we also talked about
moving some other stuff into it, namely the fake getaddrinfo support
for platforms that don't have it, the getaddrinfo caching support for
misconfigured platforms, and the code for extracting all of the local
network interfaces' addresses.

I've just tried creating the support library and putting the TSD and
local-address code into it, and it wound up being more painful than
we'd thought.  As indicated above, every program's link command needs
updating, for either static or dynamic linking.  On Solaris, running a
com_err test program now loads the socket library.  And it doesn't
help that the local-address code included headers which can't be
generated until after the com_err package is built, which can't happen
until the support library is built; I can probably work around that.


So, now I'm looking at moving the local-address code into libkrb5, and
making the one other use of it, the KDC, use krb5int_accessor to get
at the function it wants.  (We may want to make kadmind use it too, in
the passwd server support.)

The fake getaddrinfo/getnameinfo code is a little more tricky.  It's
used by libkrb5, libkrb4, libpty, the KDC, telnet, telnetd, and the
r-commands.  If it goes into the low-level support library, the
resolver library at least then gets pulled in to everything we build.
There's already another support library for application-level code,
lib/apputils, for routines like daemon().  I'm inclined to move the
getaddrinfo/getnameinfo code into libkrb5, export it with
krb5int_accessor like the local-address code, and to keep the
application code relatively clean, let them use a very stripped-down
fake-addrinfo.h and wrapper functions in lib/apputils so they don't
have to pull in all of k5-int.h.  (So aside from including
fake-addrinfo.h, they'd pretend that getaddrinfo and friends always
exists and works, which is the way we're doing it now.  Nice and easy
to undo, if the applications get split off into a separate package.)
Unless any better suggestions come along....

That brings the low-level support library back to just having the
thread-specific data support for now, a fairly tiny slice of code to
warrant a new library of its own.

Ken