[patch 1/10] Don't depend on Kerberos headers when checking librpcsecgss in configure

[Neil Brown]

On Wednesday July 5, gnb at sgi.com wrote:
> On Tue, Jul 04, 2006 at 10:32:04PM +1000, Neil Brown wrote:
> > ln -s ../export/mount.h ../../support/include/mount.h
> > ln: creating symbolic link `../../support/include/mount.h' to `../export/mount.h': File exists
> 
> An $(RM) or ln -snf should fix this.

or even "rm -f", which is what I have done.

> 
> > ./support/export/keys.c
> > ./support/include/rpcdispatch.h
> > ./support/include/rpcsec.h
> > ./support/include/version.h
> > ./support/include/ypupdate.h
> > ./support/nfs/clients.c
> > ./support/nfs/keytab.c
> > ./support/nfs/ypupdate_xdr.c
> > ./support/rpc
> > ./support/rpc/include
> > ./support/rpc/include/Makefile.am
> > ./tools/rpcdebug/neat_idea.c
> > ./utils/mountd/mount_xdr.c
> > ./utils/rquotad/pathnames.h
> 
> Yes, these all appear unused.

Thanks for double checking.  I removed references from Makefile.am
too.

> 
> So why is rpcdebug noinst?  That seems like a useful tool to ship.
> The number of times I've mucked about with echoing magic numbers
> into /proc...

All it takes is a patch, and some testing.  And maybe a man page :-)

> 
> > and maybe get rquota_???.c to be generated from
> > rquota.x
> 
> Yep.

Done, for _xdr.c and .h.  _svc.c will have to wait.

> 
> > and maybe wonder why we have our own rpcgen (but now that we have
> > fixed it, I'm loathe to remove it) when glibc seems to provide one.
> 
> Which has all the same failings we just fixed in nfs-utils' copy.
> It might be better to push those fixes into glibc's rpcgen and
> switch over to it later.

Probably.  Later.

Next on my wishlist is making the output of 'make' much quieter - more
like the kernel make.  But I suspect that would require serious auto-X
hacking and probably isn't worth it.

NeilBrown