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

[Greg Banks]

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.

> ./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.

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

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

Yep.

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

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.