Re: autoconf-2.67 - make check failure on AIX V8BETA - 2 failures

[Ralf Wildenhues]

* Rainer Tammer wrote on Mon, Aug 02, 2010 at 08:34:42AM CEST:
> On 01.08.2010 18:58, Ralf Wildenhues wrote:
> > * Rainer Tammer wrote on Sun, Aug 01, 2010 at 05:09:01PM CEST:
> >> this are the failures of autoconf 2.67 make check on AIX V7BETA:
> >>
> >> 213: AC_CACHE_CHECK     FAILED (base.at:478)
> >> 240: Signal handling                  FAILED (torture.at:1263)
> >>
> >> I have included the testsuite.log for a detailed reference.

> > For test 240, can you please post the output of the following:
> >   cd $top_builddir
> >   cd tests/testsuite.dir/240
> >   /bin/sh -vx ./configure
> >
> I have attached the configure output from AIX 7BETA and from AIX 6.1.

Thanks.

I don't get it with this test: the global testsuite.log file shows that
configure wrongly exits 0:

| 240. torture.at:1254: testing Signal handling ...
| ./torture.at:1262: autoconf --force 
| ./torture.at:1263: ./configure $configure_options 
| stderr:
| stdout:
| ./torture.at:1263: exit code was 0, expected 1
| config.log:
| > This file contains any messages produced by compilers while
| > running configure, to aid debugging if configure makes a mistake.
| > 
| > It was created by configure, which was
| > generated by GNU Autoconf 2.67.  Invocation command line was
[...]
| > #define PACKAGE_URL ""
| > 
| > configure: exit 0
| 240. torture.at:1254: 240. Signal handling (torture.at:1254): FAILED 
(torture.at:1263)

but the verbose 'sh -vx ./configure' logs show each that the signal is
caught and the exit status is nonzero, as it should be:

| + test 2 != 0
| + print -r -- configure: caught signal 2
| + print -r -- configure: exit 1
| + rm -f core *.core core.conftest.*
| + rm -f -r conftest* confdefs.h conf491566*
| + exit 1

| + test 2 != 0
| + print -r -- configure: caught signal 2
| + print -r -- configure: exit 1
| + rm -f core *.core core.conftest.*
| + rm -f -r conftest* confdefs.h conf6422580*
| + exit 1

I cannot reproduce the failure on AIX 5.3 either.
Not sure what to suggest next.  Maybe try running the configure script a
few times in a row, to see if the failure is latent?

Cheers,
Ralf