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

This is a discussion on --with-system-et : a problem with krb5-1.4.3 - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

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

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

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

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: --with-system-et : a problem with krb5-1.4.3

    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
    > , for the system copy.


    I could see going with ... 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=


    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: --with-system-et : a problem with krb5-1.4.3

    Ken Raeburn writes:

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


    RHEL 4 for some reason dropped the /usr/include/com_err.h link and now
    only has /usr/include/et/com_err.h. I have no idea why. Debian has kept
    the compatibility link.

    I've had to go through all my packages and check for et/com_err.h and do
    the:

    #ifdef HAVE_ET_COM_ERR_H
    # include
    #else
    # include
    #endif

    nonsense.

    --
    Russ Allbery (rra@stanford.edu)

+ Reply to Thread