Subject: bug#10324: [Platform-testers] Automake 1.11.1b test release

From: Peter Rosin <[email-masked]>
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