Package: automake;
Reported by: Bruno Haible <bruno <at> clisp.org>
Date: Mon, 19 Dec 2011 02:15:01 UTC
Severity: normal
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.