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

[Nicolas Williams]

On Wed, May 05, 2004 at 06:09:03PM -0400, Ken Raeburn wrote:
> 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.

Yes, a new library does seem like the way to go.  Can you merge some
utility libraries, perhaps?

> 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.

Use lazy loading and the socket library won't get loaded into the
com_err test program...

I recommend a multi-pass build: first build/install the headers, then
build/install the sources, ...

OTOH, by now you're doing radical build surgery, you might want to
consider nor moving other common code into the the thread-support
library than you have to.

> 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.

Yeah, though, again, lazy loading helps.

> 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.

What's cheaper?  More libraries?  Or more ignored (lazily loaded)
dependencies in the resulting executables?

Nico
--