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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
