Error while compiling krb 1.5

[Theodore Tso]

On Fri, Jul 07, 2006 at 05:58:33PM -0400, Marcus Watts wrote:
> which compile_et are you using?
> does it actually match the -lcom_err you're using?
> does it actually match the com_err.h you're using?
> is com_err.h under include, et, or afs?
> are you really using the one that came with ext2fs which
> 	does no locking in any case?

Yeah, sigh.  I'll note that the ext2fs version at this point is pretty
good at handling complete backwards compatibility such that compile_et
should emit .c and .h files that work with any -lcom_err
implementation, and its -lcom_err implementation will work with .c and
.h files generated by any compile_et.  In addition, it supports the
non-standard enhancements added to .et files by Heimdal.

This is *not* the case with the MIT Kerberos implementation, which has
more lax compatibility requirements, at least at one point, with some
resulting entertaining problems that were reported with Debian, that
tries to make this whole thing work together.

The ext2fs version doesn't do locking, yes, but the locking is only
needed if you have multiple threads all loading different shared
libraries and trying to register error tables at the same time.  I'd
like to add locking, but I also want to make it to be portable across
different OS's (e2fsprogs supports Solaris, *BSD, Darwin, Hurd, and a
number of other OS's in addition to Linux), *without* dragging in the
a hugely complex shared library and compatibility mess currently in
the MIT implementation.  (And BTW, for anyone wanting to propose a
solution, anything involve automake or libtool is by definition too
complex and horrible for words).

So yeah, I'm certianly interested in possible solutions that can be
integrated into e2fsprogs, but I haven't had the time to find
something that doesn't cause me to vomit all over the keyboard.  I'll
certainly take a look at your effort and see if there's idea and code
I can pull from there.

One thing which does make it easier for me as the e2fsprogs maintainer
(but not for the MIT Kerberos folks), is that I don't care about
Windows and MacOS compatibility, and so leaking memory is less of an
issue, since most programs to repeatedly load and unload shared
libraries containing error tables.  

						- Ted