Error while compiling krb 1.5

[Russ Allbery]

Theodore Tso <tytso at MIT.EDU> writes:
> On Sat, Jul 08, 2006 at 10:36:13PM -0400, Marcus Watts wrote:

>> The debian "testing" system I have seems to have exactly one
>> libcom_err, and kerberos links against that.  I actually like that.

> Yep, and debian testing uses the com_err library from e2fsprogs.

In theory, it's not entirely thread-safe; if multiple threads load new
error tables at the same time, bad things could happen.  In practice, we
decided that this was a sufficiently rare problem that it wasn't worth
trying to use the MIT Kerberos com_err library and run into all of the
hideous problems that result from multiple com_err libraries being loaded.

For correct functioning of an integrated distribution like Debian, I think
it's really important to only have one com_err library.

> (I don't know if MIT Kerberos bothered to bump the shared version
> number, but if we are going to do this right, it would be nice to
> coordinate major version numbers and carefully define what interfaces
> are guaranteed to exist as of that shared library major version.)

Yeah, this really would be nice.

> If we allow into the solution space requiring changes to threaded
> programs that want to use com_err, there are a number of things we could
> do beyond creating a separate com_err_r library.  For example, we could
> simply require that threaded programs call a function,
> com_err_enable_pthread().

One of the problems with any approach like this is that the threaded
application often isn't calling com_err directly and has no idea that
com_err actually exists.  Consider, for instance, a threaded application
that uses GSS-API via calls through the MIT Kerberos GSS-API library.
com_err is initialized internal to the MIT Kerberos library, which has to
handle both threaded and non-threaded programs.  I suppose you could do
some magic inside the MIT Kerberos library that detects whether it's
running threaded and then calls the appropriate initialization function.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>