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.
View this message in rfc822 format
From: Peter Rosin <peda <at> lysator.liu.se> To: 10324 <at> debbugs.gnu.org Subject: 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.