GNU bug report logs - #10324
[Platform-testers] Automake 1.11.1b test release

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10324 in the body.
You can then email your comments to 10324 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-automake <at> gnu.org
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 03:11:42 +0100

[Message part 1 (text/plain, inline)]

> The pre-release automake version 1.11.1b is now available at
> <ftp://alpha.gnu.org/gnu/automake>.

Some builds took longer. Here are the results:

===============================================================================

* Linux/PowerPC

FAIL: lzma.test

The test-suite.log shows this:

tardir=lzma-1.0 && /bin/bash /home/haible/multibuild-1552/linuxppc32/automake-1.11.1b/tests/lzma.dir/missing --run tar chof - "$tardir" | lzma -9 -c >lzma-1.0.tar.lzma
lzma: Cannot allocate memory
tar: -: Wrote only 4096 of 10240 bytes
tar: Error is not recoverable: exiting now
tar: -: Cannot write: Broken pipe
tar: Error is not recoverable: exiting now
tar: -: Cannot write: Broken pipe
tar: Error is not recoverable: exiting now
WARNING: I can't seem to be able to run `tar' with the given arguments.
         You may want to install GNU tar or Free paxutils, or check the
         command line arguments.
make: *** [dist] Error 1

The 'lzma' process apparently exceeds the ulimits for memory or virtual
memory set on this machine. Maybe you can reduce the compression option:
-9 takes a huge amount of memory, as you can see from
http://tukaani.org/lzma/benchmarks.html section "Memory requirements".

===============================================================================

* Linux/PowerPC 64-bit

FAIL: silent-many-generic.test

Find attached the log file. I configured Automake with
CC="gcc -m64"; export CC;
CXX="g++ -m64"; export CXX;
CPPFLAGS="-Wall"; export CPPFLAGS;
./configure --prefix=$HOME/prefix-linux-ppc64

Apparently a 32-bit libfl.a and libfl.so exists in /usr/lib, but no 64-bit
libfl.a and libfl.so exists in /usr/lib64. The AC_PROG_LEX macro apparently
does not detect the missing library support, so it gets unnoticed until the
linker complains.

===============================================================================

* mingw

All 795 tests behaved as expected (11 expected failures)

===============================================================================

* msvc9

FAIL: silent-lex-generic.test

This is due to the use of <unistd.h> in the flex-generated <unistd.h>.
When gnulib is in use, it is ok to use <unistd.h> on MSVC platforms, but
without gnulib, it doesn't work.

FAIL: specflg10.test

Problem with the dependency support.

Find attached the log file.

I used the configuration commands

CC="$HOME/msvc/compile cl -nologo"; export CC;
CFLAGS=""; export CFLAGS;
CXX="$HOME/msvc/compile cl -nologo"; export CXX;
CXXFLAGS=""; export CXXFLAGS;
CPPFLAGS="-D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include"; export CPPFLAGS;
LDFLAGS="-L/usr/local/msvc/lib"; export LDFLAGS;
LD="link"; export LD;
NM="dumpbin -symbols"; export NM;
STRIP=":"; export STRIP;
AR="$HOME/msvc/ar-lib lib"; export AR;
RANLIB=":"; export RANLIB;
./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc

===============================================================================

* Cygwin 1.7.9

19 of 808 tests failed

FAIL: distcheck-override-infodir.test
FAIL: fort4.test
FAIL: gettext.test
FAIL: instdir-texi.test
FAIL: parallel-am.test
FAIL: txinfo3.test
FAIL: txinfo13.test
FAIL: txinfo16.test
FAIL: txinfo18.test
FAIL: txinfo21.test
FAIL: txinfo22.test
FAIL: txinfo23.test
FAIL: txinfo24.test
FAIL: txinfo25.test
FAIL: txinfo28.test
FAIL: txinfo33.test
FAIL: transform2.test
FAIL: version7.test
FAIL: vtexi4.test

Is the attached log file enough for you to investigate? You have access to
the machine.

===============================================================================

Bruno

[linuxppc64-test-suite.log (text/x-log, attachment)]

[msvc9-test-suite.log.gz (application/x-gzip, attachment)]

[cygwin-1.7.9-test-suite.log.gz (application/x-gzip, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: bug-automake <at> gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 06:51:50 +0100

Bruno Haible skrev 2011-12-19 03:11:

*snip*

> * Cygwin 1.7.9
> 
> 19 of 808 tests failed
> 
> FAIL: distcheck-override-infodir.test
> FAIL: fort4.test
> FAIL: gettext.test
> FAIL: instdir-texi.test
> FAIL: parallel-am.test
> FAIL: txinfo3.test
> FAIL: txinfo13.test
> FAIL: txinfo16.test
> FAIL: txinfo18.test
> FAIL: txinfo21.test
> FAIL: txinfo22.test
> FAIL: txinfo23.test
> FAIL: txinfo24.test
> FAIL: txinfo25.test
> FAIL: txinfo28.test
> FAIL: txinfo33.test
> FAIL: transform2.test
> FAIL: version7.test
> FAIL: vtexi4.test
> 
> Is the attached log file enough for you to investigate? You have access to
> the machine.

You need this:
http://cygwin.com/ml/cygwin/2011-11/msg00393.html

Cheers,
Peter

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: bug-automake <at> gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 10:35:25 +0100

Bruno Haible skrev 2011-12-19 03:11:
>> The pre-release automake version 1.11.1b is now available at
>> <ftp://alpha.gnu.org/gnu/automake>.
> 
> Some builds took longer. Here are the results:
> 
> ===============================================================================
> 
> * Linux/PowerPC
> 
> FAIL: lzma.test
> 
> The test-suite.log shows this:
> 
> tardir=lzma-1.0 && /bin/bash /home/haible/multibuild-1552/linuxppc32/automake-1.11.1b/tests/lzma.dir/missing --run tar chof - "$tardir" | lzma -9 -c >lzma-1.0.tar.lzma
> lzma: Cannot allocate memory
> tar: -: Wrote only 4096 of 10240 bytes
> tar: Error is not recoverable: exiting now
> tar: -: Cannot write: Broken pipe
> tar: Error is not recoverable: exiting now
> tar: -: Cannot write: Broken pipe
> tar: Error is not recoverable: exiting now
> WARNING: I can't seem to be able to run `tar' with the given arguments.
>          You may want to install GNU tar or Free paxutils, or check the
>          command line arguments.
> make: *** [dist] Error 1
> 
> The 'lzma' process apparently exceeds the ulimits for memory or virtual
> memory set on this machine. Maybe you can reduce the compression option:
> -9 takes a huge amount of memory, as you can see from
> http://tukaani.org/lzma/benchmarks.html section "Memory requirements".

As a workaround, you can perhaps get around it with

	XZ_DEFAULTS=--memlimit=250MiB

or something similar in your environment. At least if your lzma
implementation is from the xz dist.

> ===============================================================================
> 
> * msvc9
> 
> FAIL: silent-lex-generic.test
> 
> This is due to the use of <unistd.h> in the flex-generated <unistd.h>.
> When gnulib is in use, it is ok to use <unistd.h> on MSVC platforms, but
> without gnulib, it doesn't work.
> 
> FAIL: specflg10.test
> 
> Problem with the dependency support.
> 
> Find attached the log file.
> 
> I used the configuration commands
> 
> CC="$HOME/msvc/compile cl -nologo"; export CC;
> CFLAGS=""; export CFLAGS;
> CXX="$HOME/msvc/compile cl -nologo"; export CXX;
> CXXFLAGS=""; export CXXFLAGS;
> CPPFLAGS="-D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include"; export CPPFLAGS;
> LDFLAGS="-L/usr/local/msvc/lib"; export LDFLAGS;
> LD="link"; export LD;
> NM="dumpbin -symbols"; export NM;
> STRIP=":"; export STRIP;
> AR="$HOME/msvc/ar-lib lib"; export AR;
> RANLIB=":"; export RANLIB;
> ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc

This smells like a testsuite weakness of some kind.  The testcase
specifies

	required=g++

but that fails to completely beat CXX=...cl... from the environment.
If I run the configure script outside of the testcase, I get

$ ./configure \
CC="/home/peda/automake-1.11.1b/lib/compile cl -nologo" \
CXX="/home/peda/automake-1.11.1b/lib/compile cl -nologo"
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... obj
checking whether we are using the GNU C compiler... no
checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
checking whether we are using the GNU C++ compiler... no
checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sub/Makefile
config.status: creating sub2/Makefile
config.status: executing depfiles commands

But configure when run from within the test outputs this:

+ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... obj
checking whether we are using the GNU C compiler... no
checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... gcc3
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sub/Makefile
config.status: creating sub2/Makefile
config.status: executing depfiles commands

Notice how g++ gets back in the game near the end. What's up with that?

Cheers,
Peter

Message #14 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 10:58:09 +0100

[Bruno: Sorry, I failed to keep your address in the replies, see also
http://lists.gnu.org/archive/html/bug-automake/2011-12/msg00052.html
which has a workaround for some of your Cygwin troubles. Maybe you
got a copy from the bug tracker, I don't know...]

Peter Rosin skrev 2011-12-19 10:35:
> Bruno Haible skrev 2011-12-19 03:11:
>>> The pre-release automake version 1.11.1b is now available at
>>> <ftp://alpha.gnu.org/gnu/automake>.
>>
>> Some builds took longer. Here are the results:
>>
>> ===============================================================================
>>
>> * Linux/PowerPC
>>
>> FAIL: lzma.test
>>
>> The test-suite.log shows this:
>>
>> tardir=lzma-1.0 && /bin/bash /home/haible/multibuild-1552/linuxppc32/automake-1.11.1b/tests/lzma.dir/missing --run tar chof - "$tardir" | lzma -9 -c >lzma-1.0.tar.lzma
>> lzma: Cannot allocate memory
>> tar: -: Wrote only 4096 of 10240 bytes
>> tar: Error is not recoverable: exiting now
>> tar: -: Cannot write: Broken pipe
>> tar: Error is not recoverable: exiting now
>> tar: -: Cannot write: Broken pipe
>> tar: Error is not recoverable: exiting now
>> WARNING: I can't seem to be able to run `tar' with the given arguments.
>>          You may want to install GNU tar or Free paxutils, or check the
>>          command line arguments.
>> make: *** [dist] Error 1
>>
>> The 'lzma' process apparently exceeds the ulimits for memory or virtual
>> memory set on this machine. Maybe you can reduce the compression option:
>> -9 takes a huge amount of memory, as you can see from
>> http://tukaani.org/lzma/benchmarks.html section "Memory requirements".
> 
> As a workaround, you can perhaps get around it with
> 
> 	XZ_DEFAULTS=--memlimit=250MiB
> 
> or something similar in your environment. At least if your lzma
> implementation is from the xz dist.
> 
>> ===============================================================================
>>
>> * msvc9
>>
>> FAIL: silent-lex-generic.test
>>
>> This is due to the use of <unistd.h> in the flex-generated <unistd.h>.
>> When gnulib is in use, it is ok to use <unistd.h> on MSVC platforms, but
>> without gnulib, it doesn't work.
>>
>> FAIL: specflg10.test
>>
>> Problem with the dependency support.
>>
>> Find attached the log file.
>>
>> I used the configuration commands
>>
>> CC="$HOME/msvc/compile cl -nologo"; export CC;
>> CFLAGS=""; export CFLAGS;
>> CXX="$HOME/msvc/compile cl -nologo"; export CXX;
>> CXXFLAGS=""; export CXXFLAGS;
>> CPPFLAGS="-D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include"; export CPPFLAGS;
>> LDFLAGS="-L/usr/local/msvc/lib"; export LDFLAGS;
>> LD="link"; export LD;
>> NM="dumpbin -symbols"; export NM;
>> STRIP=":"; export STRIP;
>> AR="$HOME/msvc/ar-lib lib"; export AR;
>> RANLIB=":"; export RANLIB;
>> ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc
> 
> This smells like a testsuite weakness of some kind.  The testcase
> specifies
> 
> 	required=g++
> 
> but that fails to completely beat CXX=...cl... from the environment.
> If I run the configure script outside of the testcase, I get
> 
> $ ./configure \
> CC="/home/peda/automake-1.11.1b/lib/compile cl -nologo" \
> CXX="/home/peda/automake-1.11.1b/lib/compile cl -nologo"
> checking for a BSD-compatible install... /bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
> checking whether the C compiler works... yes
> checking for C compiler default output file name... conftest.exe
> checking for suffix of executables... .exe
> checking whether we are cross compiling... no
> checking for suffix of object files... obj
> checking whether we are using the GNU C compiler... no
> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
> checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
> checking whether we are using the GNU C++ compiler... no
> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating sub/Makefile
> config.status: creating sub2/Makefile
> config.status: executing depfiles commands
> 
> But configure when run from within the test outputs this:
> 
> + ./configure
> checking for a BSD-compatible install... /bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
> checking whether the C compiler works... yes
> checking for C compiler default output file name... conftest.exe
> checking for suffix of executables... .exe
> checking whether we are cross compiling... no
> checking for suffix of object files... obj
> checking whether we are using the GNU C compiler... no
> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
> checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
> checking whether we are using the GNU C++ compiler... no
> checking whether g++ accepts -g... no
> checking dependency style of g++... gcc3
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating sub/Makefile
> config.status: creating sub2/Makefile
> config.status: executing depfiles commands
> 
> Notice how g++ gets back in the game near the end. What's up with that?

Does the below patch help?

Cheers,
Peter

diff --git a/tests/specflg10.test b/tests/specflg10.test
index efe13f5..ea82e1f 100755
--- a/tests/specflg10.test
+++ b/tests/specflg10.test
@@ -16,7 +16,7 @@

 # AM_DEFAULT_SOURCE_EXT

-required=g++
+required='gcc g++'
 . ./defs || Exit 1

 set -e

Message #17 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 11:14:42 +0100

Peter Rosin skrev 2011-12-19 10:58:
>>> I used the configuration commands
>>>
>>> CC="$HOME/msvc/compile cl -nologo"; export CC;
>>> CFLAGS=""; export CFLAGS;
>>> CXX="$HOME/msvc/compile cl -nologo"; export CXX;
>>> CXXFLAGS=""; export CXXFLAGS;
>>> CPPFLAGS="-D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include"; export CPPFLAGS;
>>> LDFLAGS="-L/usr/local/msvc/lib"; export LDFLAGS;
>>> LD="link"; export LD;
>>> NM="dumpbin -symbols"; export NM;
>>> STRIP=":"; export STRIP;
>>> AR="$HOME/msvc/ar-lib lib"; export AR;
>>> RANLIB=":"; export RANLIB;
>>> ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc
>>
>> This smells like a testsuite weakness of some kind.  The testcase
>> specifies
>>
>> 	required=g++
>>
>> but that fails to completely beat CXX=...cl... from the environment.
>> If I run the configure script outside of the testcase, I get

Oh crap, you are crossing over from Cygwin without telling the build
system, right? Or what is your $build if you don't specify --host?
I should have known that, given that it was you... I expect weird
stuff like this to happen when stunts like that are pulled. Even if
*you* engage in such activities, please don't expect anyone else to
fix the resulting weirdness.

Cheers,
Peter

Message #20 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 18:18:30 +0100

Hi Peter.

On 12/19/2011 06:51 AM, Peter Rosin wrote:
> Bruno Haible skrev 2011-12-19 03:11:
>
> *snip*
>
>> * Cygwin 1.7.9
>>
>> 19 of 808 tests failed
>>
>> FAIL: distcheck-override-infodir.test
>> FAIL: fort4.test
>> FAIL: gettext.test
>> FAIL: instdir-texi.test
>> FAIL: parallel-am.test
>> FAIL: txinfo3.test
>> FAIL: txinfo13.test
>> FAIL: txinfo16.test
>> FAIL: txinfo18.test
>> FAIL: txinfo21.test
>> FAIL: txinfo22.test
>> FAIL: txinfo23.test
>> FAIL: txinfo24.test
>> FAIL: txinfo25.test
>> FAIL: txinfo28.test
>> FAIL: txinfo33.test
>> FAIL: transform2.test
>> FAIL: version7.test
>> FAIL: vtexi4.test
>>
>> Is the attached log file enough for you to investigate? You have access to
>> the machine.
> You need this:
> http://cygwin.com/ml/cygwin/2011-11/msg00393.html
>
Since this error has come up few times already, do you know if there is 
a simple
way for our tests to detect this Cygwin-specific TeX breakage, and so 
get skipped
instead of failing spuriously?

Thanks,
  Stefano

Message #23 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 20:33:32 +0100

Hi Bruno, thanks for the testing and the report.

Note that I will snip from my reply those parts of your message Peter has
already answered to.

On 12/19/2011 03:11 AM, Bruno Haible wrote:
>> The pre-release automake version 1.11.1b is now available at
>> <ftp://alpha.gnu.org/gnu/automake>.
> Some builds took longer. Here are the results:
>
>
> ===============================================================================
>
> * Linux/PowerPC 64-bit
>
> FAIL: silent-many-generic.test
>
> Find attached the log file. I configured Automake with
> CC="gcc -m64"; export CC;
> CXX="g++ -m64"; export CXX;
Not also FC="gfortran -m64" and F77="gfortran -m64" ?

> CPPFLAGS="-Wall"; export CPPFLAGS;
> ./configure --prefix=$HOME/prefix-linux-ppc64
>
> Apparently a 32-bit libfl.a and libfl.so exists in /usr/lib, but no 64-bit
> libfl.a and libfl.so exists in /usr/lib64. The AC_PROG_LEX macro apparently
> does not detect the missing library support, so it gets unnoticed until the
> linker complains.
>
Weird; this test have been recently improve to pass also on system which 
lack both
libfl and libl (this is done by defining a dummy `yywrap()' function in 
the `foo5.l'
file).

See also:
<http://lists.gnu.org/archive/html/automake-patches/2011-12/msg00002.html>

Update: ah-ah, I think I've understood the problem: the 
silent-many-generic.test
test still has `g++' in $required, because currently the testsuite 
doesn't provide
a better way to require a working C++ compiler; this causes $CXX to get 
set to
`g++', so that you get the inconsistent setting of "CC='gcc -m64' 
CXX=g++" in the
test case environment; hilarity ensues.  This problem will be fixed in 
the next
major version of automake (see the 
"experimental/compilers-for-testsuite" branch),
and I think it's not worth worrying about.  Just one thing though: could you
please verify that my analysis is indeed correct?  You can do so by:

  1. removing g++" and "gfortran" from the definition of `required' in
     `silent-many-generic.test', and
  2. running the test again, with the following environment:
       CC="gcc -m64" CXX="g++ -m64" FC="gfortran -m64" F77="gfortran -m64"
> * mingw
>
> All 795 tests behaved as expected (11 expected failures)
>
> ===============================================================================
>
> * msvc9
>
> FAIL: silent-lex-generic.test
>
> This is due to the use of<unistd.h>  in the flex-generated<unistd.h>.
> When gnulib is in use, it is ok to use<unistd.h>  on MSVC platforms, but
> without gnulib, it doesn't work.
>
I'm inclined to ignore this as a MSVC and/or flex limitation.  But I 
might change
my mind if someone provides a simple patch to avoid the spurious failure 
;-) ...

Thanks,
  Stefano

Message #26 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Bruno Haible <bruno <at> clisp.org>, 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 21:06:45 +0100

On 12/19/2011 10:58 AM, Peter Rosin wrote:
> [Bruno: Sorry, I failed to keep your address in the replies, see also
> http://lists.gnu.org/archive/html/bug-automake/2011-12/msg00052.html
> which has a workaround for some of your Cygwin troubles. Maybe you
> got a copy from the bug tracker, I don't know...]
>
> Peter Rosin skrev 2011-12-19 10:35:
>> Bruno Haible skrev 2011-12-19 03:11:
>>>> The pre-release automake version 1.11.1b is now available at
>>>> <ftp://alpha.gnu.org/gnu/automake>.
>>> Some builds took longer. Here are the results:
>>> ===============================================================================
>>>
>>> * msvc9
>>>
>>> FAIL: silent-lex-generic.test
>>>
>>> This is due to the use of<unistd.h>  in the flex-generated<unistd.h>.
>>> When gnulib is in use, it is ok to use<unistd.h>  on MSVC platforms, but
>>> without gnulib, it doesn't work.
>>>
>>> FAIL: specflg10.test
>>>
>>> Problem with the dependency support.
>>>
>>> Find attached the log file.
>>>
>>> I used the configuration commands
>>>
>>> CC="$HOME/msvc/compile cl -nologo"; export CC;
>>> CFLAGS=""; export CFLAGS;
>>> CXX="$HOME/msvc/compile cl -nologo"; export CXX;
>>> CXXFLAGS=""; export CXXFLAGS;
>>> CPPFLAGS="-D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include"; export CPPFLAGS;
>>> LDFLAGS="-L/usr/local/msvc/lib"; export LDFLAGS;
>>> LD="link"; export LD;
>>> NM="dumpbin -symbols"; export NM;
>>> STRIP=":"; export STRIP;
>>> AR="$HOME/msvc/ar-lib lib"; export AR;
>>> RANLIB=":"; export RANLIB;
>>> ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc
>> This smells like a testsuite weakness of some kind.  The testcase
>> specifies
>>
>> 	required=g++
>>
>> but that fails to completely beat CXX=...cl... from the environment.
>> If I run the configure script outside of the testcase, I get
>>
>> $ ./configure \
>> CC="/home/peda/automake-1.11.1b/lib/compile cl -nologo" \
>> CXX="/home/peda/automake-1.11.1b/lib/compile cl -nologo"
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... conftest.exe
>> checking for suffix of executables... .exe
>> checking whether we are cross compiling... no
>> checking for suffix of object files... obj
>> checking whether we are using the GNU C compiler... no
>> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
>> checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
>> checking for style of include used by make... GNU
>> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
>> checking whether we are using the GNU C++ compiler... no
>> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
>> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
>> configure: creating ./config.status
>> config.status: creating Makefile
>> config.status: creating sub/Makefile
>> config.status: creating sub2/Makefile
>> config.status: executing depfiles commands.

>> But configure when run from within the test outputs this:
>>
>> + ./configure
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... conftest.exe
>> checking for suffix of executables... .exe
>> checking whether we are cross compiling... no
>> checking for suffix of object files... obj
>> checking whether we are using the GNU C compiler... no
>> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
>> checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
>> checking for style of include used by make... GNU
>> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
>> checking whether we are using the GNU C++ compiler... no
>> checking whether g++ accepts -g... no
>> checking dependency style of g++... gcc3
>> configure: creating ./config.status
>> config.status: creating Makefile
>> config.status: creating sub/Makefile
>> config.status: creating sub2/Makefile
>> config.status: executing depfiles commands
>>
>> Notice how g++ gets back in the game near the end. What's up with that?
No idea, and the output above seems really weird indeed...  What does 
config.log says
about why the check for "whether we are using the GNU C++ compiler" 
returned "no"?

> Does the below patch help?
>
> Cheers,
> Peter
>
> diff --git a/tests/specflg10.test b/tests/specflg10.test
> index efe13f5..ea82e1f 100755
> --- a/tests/specflg10.test
> +++ b/tests/specflg10.test
> @@ -16,7 +16,7 @@
>
>   # AM_DEFAULT_SOURCE_EXT
>
> -required=g++
> +required='gcc g++'
Micro-nit: here, I'd also like to see a "FIXME" comments stating that we 
should modify
this to a requirement of generic (non GCC-only) C and C++ compilers at a 
later moment
(e.g., when we merge into master).  For the rest, your fix seems good 
(assuming it
truly works ;-)

Thanks,
  Stefano

Message #29 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Bruno Haible <bruno <at> clisp.org>, 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 10:40:30 +0100

Stefano Lattarini skrev 2011-12-19 21:06:
> On 12/19/2011 10:58 AM, Peter Rosin wrote:
>> [Bruno: Sorry, I failed to keep your address in the replies, see also
>> http://lists.gnu.org/archive/html/bug-automake/2011-12/msg00052.html
>> which has a workaround for some of your Cygwin troubles. Maybe you
>> got a copy from the bug tracker, I don't know...]
>>
>> Peter Rosin skrev 2011-12-19 10:35:
>>> Bruno Haible skrev 2011-12-19 03:11:
>>>>> The pre-release automake version 1.11.1b is now available at
>>>>> <ftp://alpha.gnu.org/gnu/automake>.
>>>> Some builds took longer. Here are the results:
>>>> ===============================================================================
>>>>
>>>> * msvc9
>>>>
>>>> FAIL: silent-lex-generic.test
>>>>
>>>> This is due to the use of<unistd.h>  in the flex-generated<unistd.h>.
>>>> When gnulib is in use, it is ok to use<unistd.h>  on MSVC platforms, but
>>>> without gnulib, it doesn't work.
>>>>
>>>> FAIL: specflg10.test
>>>>
>>>> Problem with the dependency support.
>>>>
>>>> Find attached the log file.
>>>>
>>>> I used the configuration commands
>>>>
>>>> CC="$HOME/msvc/compile cl -nologo"; export CC;
>>>> CFLAGS=""; export CFLAGS;
>>>> CXX="$HOME/msvc/compile cl -nologo"; export CXX;
>>>> CXXFLAGS=""; export CXXFLAGS;
>>>> CPPFLAGS="-D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include"; export CPPFLAGS;
>>>> LDFLAGS="-L/usr/local/msvc/lib"; export LDFLAGS;
>>>> LD="link"; export LD;
>>>> NM="dumpbin -symbols"; export NM;
>>>> STRIP=":"; export STRIP;
>>>> AR="$HOME/msvc/ar-lib lib"; export AR;
>>>> RANLIB=":"; export RANLIB;
>>>> ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc
>>> This smells like a testsuite weakness of some kind.  The testcase
>>> specifies
>>>
>>>     required=g++
>>>
>>> but that fails to completely beat CXX=...cl... from the environment.
>>> If I run the configure script outside of the testcase, I get
>>>
>>> $ ./configure \
>>> CC="/home/peda/automake-1.11.1b/lib/compile cl -nologo" \
>>> CXX="/home/peda/automake-1.11.1b/lib/compile cl -nologo"
>>> checking for a BSD-compatible install... /bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... conftest.exe
>>> checking for suffix of executables... .exe
>>> checking whether we are cross compiling... no
>>> checking for suffix of object files... obj
>>> checking whether we are using the GNU C compiler... no
>>> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
>>> checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
>>> checking for style of include used by make... GNU
>>> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
>>> checking whether we are using the GNU C++ compiler... no
>>> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
>>> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
>>> configure: creating ./config.status
>>> config.status: creating Makefile
>>> config.status: creating sub/Makefile
>>> config.status: creating sub2/Makefile
>>> config.status: executing depfiles commands.
> 
>>> But configure when run from within the test outputs this:
>>>
>>> + ./configure
>>> checking for a BSD-compatible install... /bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking for gcc... /home/peda/automake-1.11.1b/lib/compile cl -nologo
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... conftest.exe
>>> checking for suffix of executables... .exe
>>> checking whether we are cross compiling... no
>>> checking for suffix of object files... obj
>>> checking whether we are using the GNU C compiler... no
>>> checking whether /home/peda/automake-1.11.1b/lib/compile cl -nologo accepts -g... no
>>> checking for /home/peda/automake-1.11.1b/lib/compile cl -nologo option to accept ISO C89... none needed
>>> checking for style of include used by make... GNU
>>> checking dependency style of /home/peda/automake-1.11.1b/lib/compile cl -nologo... msvc7msys
>>> checking whether we are using the GNU C++ compiler... no
>>> checking whether g++ accepts -g... no
>>> checking dependency style of g++... gcc3
>>> configure: creating ./config.status
>>> config.status: creating Makefile
>>> config.status: creating sub/Makefile
>>> config.status: creating sub2/Makefile
>>> config.status: executing depfiles commands
>>>
>>> Notice how g++ gets back in the game near the end. What's up with that?
> No idea, and the output above seems really weird indeed...  What does config.log says
> about why the check for "whether we are using the GNU C++ compiler" returned "no"?

No, it does not say anything about it, but I added some extra trace output
to configure to figure out what was going on. $ac_objext is detected using
cl when analyzing the C compiler properties and is set to ".obj", but g++
of course generates ".o" objects and then configure detects that "g++ -c
conftest.cpp" fails to create a conftest.$ac_objext aka conftest.obj (it
naturally produces a conftest.o file) and reports that fact as "no, not
using the GNU C++ compiler".

So, a case of "mixing compilers" which was what I suspected, and my below
patch should fix this. But I haven't tested it with Brunos settings (for
which the fix will likely be a remedy for a much worse mix, since one of
the compilers are likely cl and the other cygwin-g++)...

>> Does the below patch help?
>>
>> Cheers,
>> Peter
>>
>> diff --git a/tests/specflg10.test b/tests/specflg10.test
>> index efe13f5..ea82e1f 100755
>> --- a/tests/specflg10.test
>> +++ b/tests/specflg10.test
>> @@ -16,7 +16,7 @@
>>
>>   # AM_DEFAULT_SOURCE_EXT
>>
>> -required=g++
>> +required='gcc g++'
> Micro-nit: here, I'd also like to see a "FIXME" comments stating that we should modify
> this to a requirement of generic (non GCC-only) C and C++ compilers at a later moment
> (e.g., when we merge into master).  For the rest, your fix seems good (assuming it
> truly works ;-)

I'm waiting for confirmation that it works, and I'm not going to have
much time the following days, so you might be better off handling it
yourself, if you have some agenda due to the pending release.

Cheers,
Peter

Message #32 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Bruno Haible <bruno <at> clisp.org>, 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 10:45:03 +0100

On 12/20/2011 10:40 AM, Peter Rosin wrote:
>
> I'm waiting for confirmation that it works, and I'm not going to have
> much time the following days, so you might be better off handling it
> yourself, if you have some agenda due to the pending release.
>
No problem, I will commit the fix once I have confirmation that it works.

Thanks,
  Stefano

Message #35 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 15:20:05 +0100

On 12/19/2011 03:11 AM, Bruno Haible wrote:
> ===============================================================================
> 
> * msvc9
> 
> FAIL: specflg10.test
> 
> Problem with the dependency support.
> 
> Find attached the log file.
> 
> I used the configuration commands
> 
> CC="$HOME/msvc/compile cl -nologo"; export CC;
> CFLAGS=""; export CFLAGS;
> CXX="$HOME/msvc/compile cl -nologo"; export CXX;
> CXXFLAGS=""; export CXXFLAGS;
> CPPFLAGS="-D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include"; export CPPFLAGS;
> LDFLAGS="-L/usr/local/msvc/lib"; export LDFLAGS;
> LD="link"; export LD;
> NM="dumpbin -symbols"; export NM;
> STRIP=":"; export STRIP;
> AR="$HOME/msvc/ar-lib lib"; export AR;
> RANLIB=":"; export RANLIB;
> ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc
> 
Ah-ah, I think I've found the "real" problem here.  Currently (i.e., in maint),
the code in `tests/defs' doesn't set nor export the values of $host_alias and/or
$build_alias determined at configure time; so your environment setup above above
isn't enough to trigger a true cross-compilation run of the testsuite; you
need at least this additional setting:

  host_alias=i586-pc-mingw32; export host_alias

and probably, to be sure to avoid spurious failures, also this one:

  build_alias=`./lib/config.guess`; export build_alias

This testsuite weakness will be fixed in the next major version of Automake.

Thanks, and sorry for the confusion,
  Stefano

Message #38 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Bruno Haible <bruno <at> clisp.org>, 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 21:15:19 +0100

Stefano Lattarini skrev 2011-12-19 20:33:
> Hi Bruno, thanks for the testing and the report.
> 
> Note that I will snip from my reply those parts of your message Peter has
> already answered to.
> 
> On 12/19/2011 03:11 AM, Bruno Haible wrote:
>> * msvc9
>>
>> FAIL: silent-lex-generic.test
>>
>> This is due to the use of<unistd.h>  in the flex-generated<unistd.h>.
>> When gnulib is in use, it is ok to use<unistd.h>  on MSVC platforms, but
>> without gnulib, it doesn't work.
>>
> I'm inclined to ignore this as a MSVC and/or flex limitation.  But I might change
> my mind if someone provides a simple patch to avoid the spurious failure ;-) ...

How about this for maint? Caution, I'm pretty much ignorant of lex details...

Cheers,
Peter

2011-12-20  Peter Rosin  <peda <at> lysator.liu.se>

	tests: fix spurious failure on systems lacking unistd.h
	* tests/silent-lex-generic.test (foo.l): Don't require unistd.h
	to be present.

diff --git a/tests/silent-lex-generic.test b/tests/silent-lex-generic.test
index 2b2183e..a1c19ea 100755
--- a/tests/silent-lex-generic.test
+++ b/tests/silent-lex-generic.test
@@ -53,6 +53,10 @@ LDADD = $(LEXLIB)
 EOF
 
 cat > foo.l <<'EOF'
+%{
+/* avoid non-ANSI #include of unistd.h */
+#define YY_NO_UNISTD_H
+%}
 %%
 "END"   return EOF;
 .

Message #41 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Bruno Haible <bruno <at> clisp.org>, 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 21:30:34 +0100

Hi Peter, thanks for the patch.

On 12/20/2011 09:15 PM, Peter Rosin wrote:
> 
> How about this for maint? Caution, I'm pretty much ignorant of lex details...
>
Surely no more than I am, so I'll follow your lead.  I just have a couple of nits below.

> Cheers,
> Peter
> 
> 2011-12-20  Peter Rosin  <peda <at> lysator.liu.se>
> 
> 	tests: fix spurious failure on systems lacking unistd.h
> 	* tests/silent-lex-generic.test (foo.l): Don't require unistd.h
> 	to be present.
>
Here, I'd report the bug number and the name of the affected system as well; something
like this:

	tests: fix spurious failure on systems lacking unistd.h
        This is for automake bug#10324.
	* tests/silent-lex-generic.test (foo.l): Add a dummy #define of YY_NO_UNISTD_H,
	so that the generated foo.c file won't require unistd.h	to be present (it is
	not when compiling with, e.g., MSVC 9).

ACK with this addressed, if you can confirm your change fixes the spurious failure
(but I bet you've already checked that ;-)

> diff --git a/tests/silent-lex-generic.test b/tests/silent-lex-generic.test
> index 2b2183e..a1c19ea 100755
> --- a/tests/silent-lex-generic.test
> +++ b/tests/silent-lex-generic.test
> @@ -53,6 +53,10 @@ LDADD = $(LEXLIB)
>  EOF
>  
>  cat > foo.l <<'EOF'
> +%{
> +/* avoid non-ANSI #include of unistd.h */
> +#define YY_NO_UNISTD_H
>
Micro-nit: maybe define this to '1' for clarity & safeness?  (This is not a
requirement for an ACK though, just a matter of preference).

> +%}
>  %%
>  "END"   return EOF;
>  .

Thanks,
  Stefano

Message #44 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 21:31:47 +0100

Stefano Lattarini skrev 2011-12-19 18:18:
> Hi Peter.
> 
> On 12/19/2011 06:51 AM, Peter Rosin wrote:
>> Bruno Haible skrev 2011-12-19 03:11:
>>
>> *snip*
>>
>>> * Cygwin 1.7.9
>>>
>>> 19 of 808 tests failed
>>>
>>> FAIL: distcheck-override-infodir.test
>>> FAIL: fort4.test
>>> FAIL: gettext.test
>>> FAIL: instdir-texi.test
>>> FAIL: parallel-am.test
>>> FAIL: txinfo3.test
>>> FAIL: txinfo13.test
>>> FAIL: txinfo16.test
>>> FAIL: txinfo18.test
>>> FAIL: txinfo21.test
>>> FAIL: txinfo22.test
>>> FAIL: txinfo23.test
>>> FAIL: txinfo24.test
>>> FAIL: txinfo25.test
>>> FAIL: txinfo28.test
>>> FAIL: txinfo33.test
>>> FAIL: transform2.test
>>> FAIL: version7.test
>>> FAIL: vtexi4.test
>>>
>>> Is the attached log file enough for you to investigate? You have access to
>>> the machine.
>> You need this:
>> http://cygwin.com/ml/cygwin/2011-11/msg00393.html
>>
> Since this error has come up few times already, do you know if there is a simple
> way for our tests to detect this Cygwin-specific TeX breakage, and so get skipped
> instead of failing spuriously?

No, I don't, not off the top of my head.  But I suppose one could extend
the test during configure and check if TeX actually works.

But, I have never written any TeX input from scratch and don't really
know how to trigger the problem. So, I expect this will take me quite
a bit of digging to work around. And I'm not really keen on it when
it's seems so annoyingly easy for Cygwin to fix the real problem
instead and be done with it.

Cheers,
Peter

Message #47 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 21:35:34 +0100

On 12/20/2011 09:31 PM, Peter Rosin wrote:
> Stefano Lattarini skrev 2011-12-19 18:18:
>> Hi Peter.
>>
>> On 12/19/2011 06:51 AM, Peter Rosin wrote:
>>> Bruno Haible skrev 2011-12-19 03:11:
>>>
>>> *snip*
>>>
>>>> * Cygwin 1.7.9
>>>>
>>>> 19 of 808 tests failed
>>>>
>>>> FAIL: distcheck-override-infodir.test
>>>> FAIL: fort4.test
>>>> FAIL: gettext.test
>>>> FAIL: instdir-texi.test
>>>> FAIL: parallel-am.test
>>>> FAIL: txinfo3.test
>>>> FAIL: txinfo13.test
>>>> FAIL: txinfo16.test
>>>> FAIL: txinfo18.test
>>>> FAIL: txinfo21.test
>>>> FAIL: txinfo22.test
>>>> FAIL: txinfo23.test
>>>> FAIL: txinfo24.test
>>>> FAIL: txinfo25.test
>>>> FAIL: txinfo28.test
>>>> FAIL: txinfo33.test
>>>> FAIL: transform2.test
>>>> FAIL: version7.test
>>>> FAIL: vtexi4.test
>>>>
>>>> Is the attached log file enough for you to investigate? You have access to
>>>> the machine.
>>> You need this:
>>> http://cygwin.com/ml/cygwin/2011-11/msg00393.html
>>>
>> Since this error has come up few times already, do you know if there is a simple
>> way for our tests to detect this Cygwin-specific TeX breakage, and so get skipped
>> instead of failing spuriously?
> 
> No, I don't, not off the top of my head.  But I suppose one could extend
> the test during configure and check if TeX actually works.
> 
> But, I have never written any TeX input from scratch and don't really
> know how to trigger the problem. So, I expect this will take me quite
> a bit of digging to work around. And I'm not really keen on it when
> it's seems so annoyingly easy for Cygwin to fix the real problem
> instead and be done with it.
> 
> Cheers,
> Peter
>
OK, then I say we'll attempt a workaround only after 1.11.2, and only if we receive
"enough" bug reports about these spurious failures to make a workaround worthwhile.

Thanks,
  Stefano

Message #50 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Bruno Haible <bruno <at> clisp.org>, 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Tue, 20 Dec 2011 21:48:11 +0100

Stefano Lattarini skrev 2011-12-20 21:30:
> Hi Peter, thanks for the patch.
> 
> On 12/20/2011 09:15 PM, Peter Rosin wrote:
>>
>> How about this for maint? Caution, I'm pretty much ignorant of lex details...
>>
> Surely no more than I am, so I'll follow your lead.  I just have a couple of nits below.

Heh, I wouldn't bet on it. This was a first for me... :-)

>> Cheers,
>> Peter
>>
>> 2011-12-20  Peter Rosin  <peda <at> lysator.liu.se>
>>
>> 	tests: fix spurious failure on systems lacking unistd.h
>> 	* tests/silent-lex-generic.test (foo.l): Don't require unistd.h
>> 	to be present.
>>
> Here, I'd report the bug number and the name of the affected system as well; something
> like this:
> 
> 	tests: fix spurious failure on systems lacking unistd.h
>         This is for automake bug#10324.
> 	* tests/silent-lex-generic.test (foo.l): Add a dummy #define of YY_NO_UNISTD_H,
> 	so that the generated foo.c file won't require unistd.h	to be present (it is
> 	not when compiling with, e.g., MSVC 9).
> 
> ACK with this addressed, if you can confirm your change fixes the spurious failure
> (but I bet you've already checked that ;-)

Yes, it fixes the problem and one system which has unistd.h also still passes.

>> diff --git a/tests/silent-lex-generic.test b/tests/silent-lex-generic.test
>> index 2b2183e..a1c19ea 100755
>> --- a/tests/silent-lex-generic.test
>> +++ b/tests/silent-lex-generic.test
>> @@ -53,6 +53,10 @@ LDADD = $(LEXLIB)
>>  EOF
>>  
>>  cat > foo.l <<'EOF'
>> +%{
>> +/* avoid non-ANSI #include of unistd.h */
>> +#define YY_NO_UNISTD_H
>>
> Micro-nit: maybe define this to '1' for clarity & safeness?  (This is not a
> requirement for an ACK though, just a matter of preference).

Done.

>> +%}
>>  %%
>>  "END"   return EOF;
>>  .

So, all nits fixed and pushed.

Cheers,
Peter

Message #55 received at 10324-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 10324-done <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Fri, 30 Dec 2011 15:25:37 +0100

On 12/19/2011 03:11 AM, Bruno Haible wrote:
>> The pre-release automake version 1.11.1b is now available at
>> <ftp://alpha.gnu.org/gnu/automake>.
> 
> Some builds took longer.
>
[SNIP]

It seems to me that all the failures reported here have been either fixed
or fully understood and taken into account.  I'm thus closing this bug report.

If some of those failures represent themselves in further testing, please
report each of them in a separate, new bug report.

Thanks again for all the testing,
  Stefano

Message #58 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-automake <at> gnu.org
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: [Platform-testers] Automake 1.11.1b test release
Date: Fri, 06 Jan 2012 18:27:42 +0100

Hi Stefano,

Replying to
<https://lists.gnu.org/archive/html/bug-automake/2011-12/msg00057.html>:

>> * Linux/PowerPC 64-bit
>> 
>> FAIL: silent-many-generic.test
>> 
>> Find attached the log file. I configured Automake with
>> CC="gcc -m64"; export CC;
>> CXX="g++ -m64"; export CXX;
>> CPPFLAGS="-Wall"; export CPPFLAGS;
>> ./configure --prefix=$HOME/prefix-linux-ppc64

> Not also FC="gfortran -m64" and F77="gfortran -m64" ?

Thanks for the hint.

> Just one thing though: could you
> please verify that my analysis is indeed correct?  You can do so by:
>
>   1. removing g++" and "gfortran" from the definition of `required' in
>      `silent-many-generic.test', and
>   2. running the test again, with the following environment:
>        CC="gcc -m64" CXX="g++ -m64" FC="gfortran -m64" F77="gfortran -m64"

Verified. When I do this, the 'silent-many-generic.test' test passes.

Bruno

Message #61 received at 10324 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 10324 <at> debbugs.gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Fri, 06 Jan 2012 19:01:02 +0100

On 01/06/2012 06:27 PM, Bruno Haible wrote:
> Hi Stefano,
> 
> Replying to
> <https://lists.gnu.org/archive/html/bug-automake/2011-12/msg00057.html>:
> 
>> Just one thing though: could you
>> please verify that my analysis is indeed correct?  You can do so by:
>>
>>   1. removing g++" and "gfortran" from the definition of `required' in
>>      `silent-many-generic.test', and
>>   2. running the test again, with the following environment:
>>        CC="gcc -m64" CXX="g++ -m64" FC="gfortran -m64" F77="gfortran -m64"
> 
> Verified. When I do this, the 'silent-many-generic.test' test passes.
>
Good!  Thanks for letting us know.  And again, thanks for all the testing.

Regards,
  Stefano

Message #64 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Peter Rosin <peda <at> lysator.liu.se>, bug-automake <at> gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Sun, 08 Jan 2012 20:45:44 +0100

Hi Peter,

You wrote in
<https://lists.gnu.org/archive/html/bug-automake/2011-12/msg00055.html>:
> Oh crap, you are crossing over from Cygwin without telling the build
> system, right? Or what is your $build if you don't specify --host?
> I should have known that, given that it was you... I expect weird
> stuff like this to happen when stunts like that are pulled. Even if
> *you* engage in such activities, please don't expect anyone else to
> fix the resulting weirdness.

configure is able to deduce the build system by itself.

I built that automake prerelease once with

  ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc

and once with

  ./configure --host=i586-pc-mingw32 --build=i686-pc-cygwin --prefix=/usr/local/msvc

and the results (make and "make check") were exactly the same, except for

  1) the value of @build_alias@ (empty in the first case, i686-pc-cygwin in the
     second case). That's normal, and that's why autoconf macros and makefiles
     generally use @build@, not @build_alias@.

  2) a spurious (not reproducible) crash of bash during the execution of
     parallel-am3.test.

I'm not performing "stunts" when I'm relying on the correct default value
of @build@.

Bruno

Message #67 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Bruno Haible <bruno <at> clisp.org>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 09 Jan 2012 16:32:06 +0100

Hi Bruno,

Bruno Haible skrev 2012-01-08 20:45:
> Hi Peter,
> 
> You wrote in
> <https://lists.gnu.org/archive/html/bug-automake/2011-12/msg00055.html>:
>> Oh crap, you are crossing over from Cygwin without telling the build
>> system, right? Or what is your $build if you don't specify --host?
>> I should have known that, given that it was you... I expect weird
>> stuff like this to happen when stunts like that are pulled. Even if
>> *you* engage in such activities, please don't expect anyone else to
>> fix the resulting weirdness.
> 
> configure is able to deduce the build system by itself.
> 
> I built that automake prerelease once with
> 
>   ./configure --host=i586-pc-mingw32 --prefix=/usr/local/msvc
> 
> and once with
> 
>   ./configure --host=i586-pc-mingw32 --build=i686-pc-cygwin --prefix=/usr/local/msvc
> 
> and the results (make and "make check") were exactly the same, except for
> 
>   1) the value of @build_alias@ (empty in the first case, i686-pc-cygwin in the
>      second case). That's normal, and that's why autoconf macros and makefiles
>      generally use @build@, not @build_alias@.
> 
>   2) a spurious (not reproducible) crash of bash during the execution of
>      parallel-am3.test.
> 
> I'm not performing "stunts" when I'm relying on the correct default value
> of @build@.

Those were the differences you noticed, but there are more differences, and
one is the outcome of this test:

	checking whether we are cross compiling... yes/no

it's "no" when only specifying --host=i586-pc-mingw32 on Cygwin and "yes" when
also specifying --build=i686-pc-cygwin.  This difference can result in
weirdness, and I'm not going to waste time figuring out the details.  Your old
("Do not rely on the following", "This is fragile" and "whenever you specify
--host, be sure to specify --build too" [1]) way of invoking configure causes
configure to attempt to determine if you are cross-compiling or not by running
a generated executable.  But that's just a heuristics that happen to fail (with
a "no") in your case, and it's all (potentially) downhill from there.

Have you bothered to read through that section [1] of the Autoconf manual yet?
I pointed you to it once before [2].

Maybe the result of the cross-compile heuristic doesn't make a difference in
the Automake case, and maybe it does.  Maybe some other part of the build
ends up slightly different.  Or not.  Either way, I'm not going to spend time
finding out, and will stick to invoking configure as recommended in the
documentation.

All in all, I definitely think it's a stunt to not specify --build when --host
is specified, especially when the build system is able to execute the code
for the host system as is the case here.

Cheers,
Peter

[1] http://www.gnu.org/software/autoconf/manual/autoconf.html#Hosts-and-Cross-Compilation
[2] http://lists.gnu.org/archive/html/automake/2011-09/msg00024.html

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.