automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testsuite failures on Solaris 2.10 on SPARC (was: testsuite results


From: Dave Hart
Subject: Re: Testsuite failures on Solaris 2.10 on SPARC (was: testsuite results from master)
Date: Tue, 16 Nov 2010 21:22:32 +0000

On Tue, Nov 16, 2010 at 20:45 UTC, Ralf Wildenhues
<address@hidden> wrote:
> * Stefano Lattarini wrote on Sun, Nov 14, 2010 at 11:05:55PM CET:
>>  <http://autobuild.josefsson.org/automake/log-201011141903417895000.txt>
>
>>  checking build system type... sparc-sun-solaris2.10
>
>>  All the testsuite failures seem spurious, and due to the following
>>  rm error (in the "distclean" target, if I'm not mistaken):
>>    "rm: Unable to remove directory ...: File exists"
>>
>>  What's going on here?
>>
>>  Maybe NFS issues (wild guess)?
>
> Yes, these are NFS-related.  E.g., acloca13.test has leftover files
> .nfs6E44 and .nfs7E44 in tests/acloca13.dir/acloca13-1.0
> which correspond to install-sh and configure (or configure.lineno).
>
> This test fails reproducibly.  I cannot remove the files after the
> tests have ended.  So I suspect that these are file system issues
> that I don't have under control.

The NTP reference implementation "make distcheck" reliably fails
similarly on OpenSolaris in a NFS-mounted directory:

SunOS psp-os1 5.11 snv_111b i86pc i386 i86pc Solaris

I dug into it, because that machine is over twice as fast building NTP
as the other options, so I really wanted to make our distcheck work.
I gave up because the code was out of my control without complaining
further, but I'd still like to get around it.

The Sun NFS client intentionally defers deleting files, renaming them
to .nfsXXXX for some period of time that is not brief enough for "make
distcheck" to succeed.  If you delete a .nfs1234, don't be suprised to
see it silently renamed to .nfs5678 :)

It would be lovely from my perspective if Automake-generated distcheck
would ignore .nfs???? specifically and trust they will indeed be rm'd
eventually.

Cheers,
Dave Hart



reply via email to

[Prev in Thread] Current Thread [Next in Thread]