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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
