Error while compiling krb 1.5

[Marcus Watts]

Theodore Tso <tytso at mit.edu> writes:
> Date: Sat, 8 Jul 2006 13:25:19 -0400
> From: Theodore Tso <tytso at mit.edu>
> To: Marcus Watts <mdw at umich.edu>
> Cc: Jeffrey Hutzelman <jhutz at cmu.edu>, krbdev at mit.edu
> Subject: Re: Error while compiling krb 1.5
> Message-ID: <20060708172519.GA1004 at thunk.org>
> 
> 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.

The e2fsprogs compile_et won't produce tables that work with
openafs, because the error_message that's built into libafsrpc.so
(so not easily removable) doesn't export _et_list.
Sigh.

Heimdal's error_message() handles "non-standard" bases.  That is,
a table for which et->table->base is not 0 mod 256.
I don't know if this was intentional on their part,
but it's certainly useful and causes no harm.

That's useful for AFS, because AFS has a number of error code
ranges which, for various stupid reasons, have odd ranges.
It's not a trivial thing to fix inside of AFS, because the
error codes are part of the wire protocol.  The AFS code itself
handles this with hard-wired logic inside of error_message(),
but that's obviously not very generalizable (besides also being
just plain wrong -- krb5 errors are "negative", so don't
go through the afs comerr _et_list lookup logic at all.)

Another AFS complication is that one of those ranges starts at 101.
That's a problem for deciding when to use strerror(), so I prefer
to search the error table list first, then default to using strerror().
I'm not sure it's safe to assume system errors are in table 0 anyways,
or that I want system errors to override explicitly provided tables.

> 
> 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 debian "testing" system I have seems to have exactly one libcom_err,
and kerberos links against that.  I actually like that.

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

(Is is really possible to mount e2fs under solaris today?)

There is one other reason you might *like* thread-aware behavior,
and that is dealing with the "unknown error" case.  Using "static char
buffer[256];" creates the possibility that another thread might dive
in and replace the text before some previous thread succeeds in
using the error text.  More bizarre interactions are possible with
printf() which might behave oddly when printing strings in fixed-width
fields if the string changes length.

I believe all of your named os targets support pthreads, but I don't know
how many support weak references or otherwise try to make it possible
for one library to be used both by pthreads and non-pthreads
applications.  A more portable solution would probably be to provide a
separate "-lcom_err_r" that explicitly provides pthread semantics.

I can certainly see your point in not worrying about pthread support,
and even in general I'm not sure it's a good idea.  Since a lot of
the code I'm concerned about *is* using pthreads, nearly always
under linux, I figured that for me, the advantages of pthread support
outweighed its disadvantages.

I agree, automake & libtool aren't at all pretty.  I'm currently
experimenting with using a configure script written using "perl" in
place of autoconf & friends.  I'm not sure this is really the right way
to go, but I'm convinced it sucks less than automake+libtool.  Perl
*is* available on nearly all modern platforms, is often part of the
core distribution, and as it happens, most perls do know how to make
shared objects for the local environment.

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

Please feel free.  Let me know if there's anything I can do to help.
May your keyboard remain vomit-free.

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

				-Marcus