--with-system-et : a problem with krb5-1.4.3

[Bernard Leak]

Dear List,
                  a problem (of sorts) with krb5-1.4.3 has been exposed by
a recent attempt to build it (with GCC-4.0.2, though that may not
be very relevant).  The problem is that
struct et_list
(an intentionally opaque type) is not actually declared
in *your* copy of com_err.h (src/util/et/com_err.h) .  Several functions
are declared as passing around pointers to such a struct.  In the
absence of a global declaration (even a partial one:
struct et_list;
is fine) each such parameter list - or, more precisely, the right-hand
end of each such parameter list - represents a separate scope of
definition, and each of the resulting definitions are different (and
incompatible).  GCC-4.0.2 gags, rightly, on trying to force pointers
to incompatible types to each other.  You can't get round it with a
cast, because the type you need to cast to isn't visible: unless you
really want to cast to (struct *) or (void *), in which case lingering
and painful death is too good for you.

(a) First point: just add
struct et_list;
to
src/util/et/com_err.h
(outside any function declaration/definition, of course), and the
problem goes away.

(b) Second point: this problem is NOT in my copy of
/usr/include/et/com_err.h, which has just such a declaration (and
partial definition).  Yet I ran into the problem anyway!  After some
sloshing around, I observed that nothing resembling
-I/usr/include/et appears anywhere in the actual compiler
invocations, and then that src/configure never actually checks
where (or whether) com_err.h can be found.  The local copy is
being picked up, since my default inclusion path doesn't
include it - which is surely wrong: the system header should be
used, and produce the appropriate complaints if it turns out to
be incompatible with the krb5 source-code.  As it happens, the
problem went the other way, but that don't signify.
Yes, I have read src/util/et/ISSUES .  I don't quite see how it
helps - I STILL want to use the correct com_err.h, and you are
merely concealing major potential problems if you use something
else!

Considerations:
(a) if --with-system-et is specified, it must be possible to find
     com_err.h with the supplied search path (and not internally).
     If necessary, have --with-system-et-libs and --with-system-et-includes
     to find each of them separately.
(b) ... and if so, the path for locating com_err.h must appear BEFORE
      -I src/util/et/ .  On the other hand, one certainly doesn't want
      to search usr/include before ALL local paths (surely?).
      Some really weird person might have put com_err.h immediately
      inside /usr/include !  Pending international agreement that this is
      a war crime carrying a summary death penalty, it needs to be
      accommodated.  (O, for a compiler which DOES make demons fly
      out of some people's noses...)

Conclusion:
It's time, I think, to use a macro for the actual header specification
and force it through with a global header (you don't have one at
present, which is perhaps a mistake) or (what seems to be your
preferred option) add another to your vast bestiary of -D defines.

That way, you can use simply "com_err.h" (as at present)
for a locally-built 'et', and use an absolute path, such as
</usr/include/et/com_err.h>, for the system copy.  This involves
walking the inclusion path to find it - what fun! - if it isn't
explicitly specified as an 'include' option.  One brute-force
possibility; assume /usr/include/et/com_err.h UNLESS over-
ridden by --with-system-et-includes=<somewhere else>
This makes for simple testing and intelligible error messages,
but might reasonably annoy anyone who put 'et' into his
inclusion path and finds that that hasn't worked.

Fortunately, the total number of headers inviting such
treatment is conveniently small.

Bernard Leak
--
Before they made me, they broke the mould.