undefined reference to `krb5int_dbgref_dump_principal'

[Tom Yu]

"W. Trevor King" <wking at tremily.us> writes:

> I'm trying to debug some reverse DNS issues, so I tried compiling krb5
> with DEBUG_REFERRALS set in k5-int.h.  Unfortunately, this caused the
> build to crash with:
>
>   krb/gc_via_tkt.so: In function `krb5_get_cred_via_tkt_ext':
>   gc_via_tkt.c:(.text+0xa4a): undefined reference to `krb5int_dbgref_dump_principal'
>   gc_via_tkt.c:(.text+0xa62): undefined reference to `krb5int_dbgref_dump_principal'
>   os/sn2princ.so: In function `krb5_sname_to_principal':
>   sn2princ.c:(.text+0x1cd): undefined reference to `krb5int_dbgref_dump_principal'
>   collect2: ld returned 1 exit status

Typically, developers don't test debugging code once they are done
with whatever debugging task they added it for, so it doesn't surprise
me that it would fail in strange ways.  The sort of diagnostics that
you are looking for are probably better obtained through the
KRB5_TRACE functionality.  I realize that we don't have trace points
that provide that, but we could add them.

> and then removed by:
>
>   commit 1a56ea6a655b191ea2ecde21c57efe746d64c378
>   Author: Tom Yu <tlyu at mit.edu>
>   Date:   Fri Jan 2 01:40:41 2009 +0000
>
>     Rewrite walk_rtree.c to handle hierarchical traversal better and to be
>     less convoluted.  Update test cases.
>
>     ticket: 5947
>
>     git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@21659 dc483132-0cff-0310-8789-dd5450dbe970
>
> Was this removal accidental?  It seems like walk_rtree.c was rewritten
> and krb5int_dbgref_dump_principal got lost in the shuffle.

It was long enough ago that I don't know if I intentionally removed
it.

> If the removal was accidental, should I submit a bug report, with a
> patch restoring the function?  This doesn't seem like the most
> appropriate location for the function's definition anyway.  I've
> barely glanced through the code, but perhaps princ_comp.c would be a
> better place?

Feel free to submit a patch that restores the debug function, but I
think it would be even better if we replace the code that's under the
DEBUG_REFERRALS conditional with trace points for KRB5_TRACE.  Would
you be willing to help with that?  It would have the advantage of not
requiring recompilation to get the diagnostics.