Re: autoconf hangs due to autom4te.cache and NFS problem on AIX

[Ralf Wildenhues]

Hi Chris,

Thanks for the report.

* Chris Pickett wrote on Sat, Feb 23, 2008 at 06:56:36AM CET:
> Autoconf 2.61 started hanging recently for me on AIX 5.2.  I don't 
> really know what changed in the system, it could just be that some 
> clocks are slightly off... who knows what's going on.
> 
> Anyway, I decided when fixing to upgrade to the latest versions of the 
> autotools, and automake's configure hung when checking whether autoconf 
> works.  It was stuck doing this:
> 
> /bin/perl -w /path/to/bin/autom4te --language=autoconf 
> --output=/dev/null conftest.ac
> 
> I don't really know what happened, it just hung, wouldn't respond to 
> Ctrl-C, and I had to kill it.

Can you reproduce this?  Is it because you killed a previous autoconf
instance and the cache directory is still locked?

> I noticed that I couldn't delete my autom4te.cache directory:
> 
> conftest $ ll autom4te.cache/
> total 0
> -rw-r--r-- 1 pickett xxx 0 Feb 23 00:27 .nfsCC131
> 
> because of that .nfs file.  I don't really know how nfs works 
> internally, but if I delete that file manually it just comes back.

I suppose you can rename the directory (and delete it as soon as you've
reset the NFS connection).

> The solution is documented in the autom4te manual:
> 
>    As an example, to disable Autoconf caches (`autom4te.cache')
> globally, include the following lines in `~/.autom4te.cfg':

That prevents the locking, right.

While we're at telling AIX NFS stories, when doing testsuite runs for
Libtool, I keep having severe troubles, because test libraries that have
been used by test programs are being held open by the system until the
next slibclean call.  That slibclean, however, requires elevated
privileges (which of course I don't have on the test system).  This
means that typically, testsuite.dir cannot be cleaned up properly, due
to the stale NFS files.  It results in a bunch of warnings (not all from
Autotest), and I had to adjust the testsuite slightly to cope with these
semantics.  I typically move testsuite.dir before a full run, DoSing the
system slowly, and eventually ping a privileged user.

If anyone knows of a better way around this, I'd be interested.

Cheers,
Ralf