krb5 thread support and excess support libraries -- seeking opinions, options
Nicolas.Williams at sun.com
Wed May 5 18:34:53 EDT 2004
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?
More information about the krbdev