krb5 libraries and circular dependencies

[Ken Raeburn]

On May 28, 2010, at 14:38, Greg Hudson wrote:
> On Fri, 2010-05-28 at 13:43 -0400, Sam Hartman wrote:
>> I have not previously analyzed the situation where libk5crypto continues
>> to provide all the symbols it used to provide at the same symbol
>> versions.
> 
> Well, let's take a harder look.  The most workable proposal is to:
> 
>  * Build and install a libkrb5 containing all of the objects currently
> in libkrb5, libk5crypt, and libkrb5support.
> 
>  * Build and install a libk5crypto and libkrb5support containing all of
> the same objects as in the (new) libkrb5.  Neither of these would be
> mentioned by krb5-config; they would be ABI compatibility shims only.
> (Well, and shims for builds which explicitly link against -lk5crypto
> and/or -lkrb5support instead of using krb5-config.)

The Kerberos version of the com_err library depends on the support library for its conditional thread support, and the libkrb5 objects depend on the com_err library.  (I wonder if it's time yet to make the "conditional" part just go away, and make the shims map unconditionally to pthread calls on POSIX platforms?)  Getting rid of this dependency would, theoretically, make it more practical to re-merge the divergent flavors of the library.  I wouldn't suggest folding the com_err library into the mix.

> A possible concern is a process using Yarrow from both libkrb5 and
> libkrb5support during the transition period.  For instance, a rebuilt
> binary might use Yarrow from libkrb5, and also via a non-rebuilt
> intermediate library (like OpenLDAP or SASL) which uses Yarrow from
> libk5crypto.  In this case, each Yarrow would be using a separate y_ctx.
> I don't think this would be a real problem (each PRNG would be seeded by
> different OS random data), but I'm not 100% certain.

Cases like this (not Yarrow specifically, but libkrb5 vs libk5crypto versions of functions) can also lead to multiple libraries trying to register the same thread-specific-data key internally, which IIRC will cause an assertion failure.

Library finalization functions will be invoked for each library they show up in.  Library initialization functions likewise *if* the configure-time option to run them at load time is given.

Ken