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

[Ken Raeburn]

We do assume that the system com_err code is "sufficiently"  
compatible with ours, and no, we don't have the meaning of that  
codified, much less carefully tested.  Basically, if it doesn't work,  
then you have to use our version.


On Jan 23, 2006, at 18:21, Bernard Leak wrote:
> 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.

Uh, what functions are declared that way?  In my source tree, all I  
see is stuff in src/util/et, and if you're using the system com_err  
code, that shouldn't get compiled.  "struct et_list" is defined in  
src/util/et/error_table.h, and should only be used by files including  
that header.

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

Yeah, our checks are kind of weak; like I indicated, we kind of  
assume that you know that your system version is "good enough".  I  
don't know what system puts com_err.h into /usr/include/et.  (And,  
since I don't see you mentioning what system you're using, I still  
don't. :-))

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

Yeah, it might be nice... but at some point the vast pile of --with- 
foo-libs options gets to be too much, and the right answer becomes  
"just tweak CPPFLAGS/LDFLAGS".  The --with-foo-libs stuff, turning  
into -L options, also gives a false sense that you really could just  
get package foo from one place, and package bar from another, but  
really, you're adding both places (in some unknown order) to the list  
of places searched for packages foo and bar, and maybe only one of  
them in directories that only need one, etc.  So if you have a couple  
versions of header foo or library quux installed in different places,  
especially if there are dependencies between them and other things  
you need to pull in, having these multiple options can cause serious  
problems that you don't tend to think about.  The ordering issues are  
clear when CPPFLAGS and LDFLAGS are specified.

> (b) ... and if so, the path for locating com_err.h must appear BEFORE
>       -I src/util/et/ .

If --with-system-et is given, then src/util/et should not be in the  
include path at all.

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

No, in fact, I'd say the include path should be (1) build-tree and  
source-tree directories (but not including directories for packages  
for which system versions will be used), (2) configure-time specified  
directories, and then (3) /usr/include.

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

Actually the generated header include/krb5/autoconf.h is our  
preferred option, and it's included in a lot of source files (usually  
indirectly); we just haven't made switching things over to it a  
priority.

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

I could see going with <et/com_err.h> ... but maybe this is something  
to consider....

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

Actually, I was under the impression that /usr/include/com_err.h or / 
usr/include/krb5/com_err.h were pretty common.  I see my Red Hat  
system puts it in /usr/include/et, and my Debian box has both /usr/ 
include/com_err.h and /usr/include/et/com_err.h (one a symlink to the  
other).  My NetBSD 2.0 system has /usr/include/krb5/com_err.h, and my  
Solaris 10 machine doesn't seem to have it at all.

Ken