krb autoconf

[Sam Hartman]

>>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:

    Kevin> Sam, 

Hi.  IN general if there isn't a reason for confidentiality, please at
least copy the krbdev list on interactions with us.  You may get a
faster response if the member of the team you contact is busy and
you'll make it easier for us to have better internal communication.

    Kevin> I have the rpcsec_gss code ready to drop into the KRB
    Kevin> tree and it builds and works fine on OpenBSD and Linux.  

That's really great to hear.

We are still very much interested in this code.  However you should be
aware that we've reached a point in the 1.3 release cycle where we
would not feel comfortable accepting the code for 1.3.  We are still
accepting some new features, but mostly from people with commit access
and only when the feature is well contained.

A new RPC implementation does not meet this constraint; if the new RPC
library fails or runs into build problems, it makes our release
runusable.

mSo we will probably not commit the code until after the 1.3 
release.

    Kevin> I
    Kevin> thought I should compile it on Solaris before I sent it to
    Kevin> you guys.  Of course, compiling the rpc code failed
    Kevin> miserably on Solaris.  I've got most of the stuff worked
    Kevin> out, but I'm having trouble with structure members that
    Kevin> don't exist on some platforms.  Specifically, struct
    Kevin> sockaddr_in.sin_len exists on OpenBSD but not most other
    Kevin> platforms.

    Kevin> <disclaimer> I am an autoconf novice.  </disclaimer>

    Kevin> I looked at autoconf documentation and thought I could just
    Kevin> add an invocation of AC_CHECK_MEMBER to the configure.in
    Kevin> for the rpc directory.  However, the krb autoconf complains
    Kevin> this macro is unknown.

Configuring our CVS head on Solaris with Autoconf 2.53 works fine for
me.

Also, one issue we'll definitely want to be sure of before accepting
the code is that all the symbols are renamed so that the RPC library
does not shadow the operating system RPC library.  If that happens,
then NIS and other NSS-based RPC services can fail.  Arguably the OS
should be binding against versioned symbols or otherwise making sure
that it uses the right RPC library, but in practice this tends not to
happen.