On Tue, 13 Nov 2001, Tom Lane wrote:
> Bill Studenmund <wrstuden@netbsd.org> writes:
> > Still checking on a good auto-detect.
>
> ISTM that autoconf should be capable of figuring out which version of
> kerberos libraries we have --- that sort of discrepancy is exactly
> what it's designed to handle.
Yes, but I don't know of a good thing to go looking for to tell. :-)
I'm not aware of something which says "Heimdal" or "MIT". Yes, I can
personally look at the libraries, and if I see libroken and libasn1, then
chances are it's heimdal, and if I see libk5crypto (I think that's the
one), chances are it's MIT. But I'd like the configure script to be more
robust - how do we tell if we have a broken install of either type?
I'm not sure, and so I don't want to make that call.
> >> Kerberos APIs --- for example, the krb5_recvauth man pages I can find on
> >> the net describe several more parameters than our code is expecting to
> >> pass.
>
> > For krb5_recvauth()? We are using the right function signature...
>
> According to whom? I found
According to the krb5_recvauth() source code in my source tree, which is
the Heimdal tree NetBSD 1.5 shipped with.
> http://archive.ncsa.uiuc.edu/General/CC/kerberos/krb5api/krb5api4.html
> in which krb5_recvauth doesn't agree with our code. (I miscounted
> yesterday, there's only one more parameter described than we pass,
> but it's definitely not the same.)
Weird. Because of this question, I pulled down a copy of MIT kerberos, and
its prototype for krb5_recvauth() matches our usage and also Heimdal's.
I suspect that documentation is out of date, though I can't definitly
tell.
I have no idea what the rc_type (the one the docs show that we don't use)
parameter would have done.
No, I looked at the docs in the MIT kerberos I pulled down, and they list
an rc_type parameter for krb5_recvauth. The code, though, doesn't have
one! Also, nothing else in the doc refers to rc_type....
Take care,
Bill
