Re: Testsuite failures on AIX 5.3

[Ralf Wildenhues]

* Stefano Lattarini wrote on Sun, Nov 14, 2010 at 10:14:54PM CET:
>  <http://autobuild.josefsson.org/automake/log-201011141902214780000.txt>
>  > + /bin/grep -F -v @SET_MAKE@ Makefile.in
>  > + 1> Makefile.sed
>  > + make -f Makefile.sed SHELL=/bin/sh test1
>  >       echo ' @top_srcdir@/configure.in   @top_srcdir@/aclocal.m4 
> @srcdir@/Makefile.am  \
>  >              @srcdir@/Makefile.in @top_srcdir@/configure ansi2knr.1  
> ansi2knr.c \
>  >              depcomp install-sh missing    ' | grep ' ansi2knr\.c '
>  > @SHELL@: not found
>  > make: 1254-004 The error code from the last command is 1.
>  > Stop.
>  > + exit_status=2
> IMHO this is a spurious failure due to the old hackish check:
>   $FGREP -v @SET_MAKE@ Makefile.in > Makefile.sed
>   $MAKE -f Makefile.sed SHELL=$SHELL test1
> retained from older versions of ansi.test; since this check is superseded
> by the later ones:
>   $AUTOCONF
>   ./configure
>   $MAKE test1
> my suggested fix is to just drop the hackish check.

But then I'm wondering why this code did not fail in the past.
Must be a regression of some kind, either in the tests, or defs.in,
or in other code.

>  > FAIL: colon5.test (exit: 2)
>  > FAIL: colon6.test (exit: 2)
> 
> These tests fail for the same resons of ansi.test; I suggest to drop the
> older hackish checks and do more proper checks with autoconf, ./configure
> and make.  BTW, there is a pending patch of mine aimed at making the
> `colon*.test' tests more "semantic"; see:
>  <http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00110.html>

Changing that shouldn't be done to cover up a regression though.

>  > FAIL: fn99.test (exit: 2)
>  > FAIL: fn99subdir.test (exit: 2)
> 
> I'm pretty sure these tests haven't been affected by my (or yours) latest
> patches: the failure is pre-existent IMO.

Yes, indeed.  This is fairly long-standing.

> Also, the tests fails due to a
> segmentation fault in the (make-spawned) shell, so the failures are better
> investigated by someone having direct access to the system in question.

Thanks,
Ralf