[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automake 1.11.3b test release
From: |
Peter Rosin |
Subject: |
Re: Automake 1.11.3b test release |
Date: |
Wed, 28 Mar 2012 19:54:54 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 |
Stefano Lattarini skrev 2012-03-25 16:46:
> We are pleased to announce the Automake 1.11.3b test release.
*snip*
> Please report bugs and problems to <address@hidden>, and send
> general comments and feedback to <address@hidden>.
On an up-to-date Cygwin 1.7 install, nothing unexpected. It's just the
old problem with lzma.test that is worked around with
export XZ_DEFAULTS=--memlimit=20MiB
And likewise on my MSYS/MinGW install with gcc, no FAILs with that export
in place.
But if I run with the following in the environment on MSYS:
export CC='/home/peda/automake-1.11.3b/lib/compile cl -nologo'
export CFLAGS=-MD
export CXX='/home/peda/automake-1.11.3b/lib/compile cl -nologo'
export CXXFLAGS=-MD
export NM='dumpbin -symbols'
export AR='/home/peda/automake-1.11.3b/lib/ar-lib lib'
export STRIP=:
export RANLIB=:
I do get a few FAILs:
FAIL: depcomp3.test
FAIL: libtool3.test
FAIL: pr307.test
FAIL: pr401b.test
FAIL: silent-many-generic.test
I think all these FAILs are related to switching to gcc/g++ but keeping
CFLAGS/CXXFLAGS, which is a well know problem which has been fixed on
the master branch.
If you are a bit more adventurous and run with the following in the
environment on MSYS
export CC='cl -nologo'
export CFLAGS=-MD
export CXX='cl -nologo'
export CXXFLAGS=-MD
export NM='dumpbin -symbols'
export AR=lib
export STRIP=:
export RANLIB=:
you get a few more FAILs
FAIL: depcomp3.test (gcc/CFLAGS)
FAIL: libtool3.test (gcc/CFLAGS)
FAIL: pr300-ltlib.test (needs AM_PROG_AR)
FAIL: pr307.test (needs AM_PROG_AR)
FAIL: pr401b.test (needs AM_PROG_AR)
FAIL: silent-many-generic.test (flex and <unistd.h>)
FAIL: subobj9.test (see below)
FAIL: yacc-dist-nobuild-subdir.test ($MAKE -e brings in $CC)
subobj9 fails in an interesting way. The test requires g++ (but not gcc),
and then proceeds with CC=cl and CXX=g++. But cl wants OBJEXT=obj while g++
wants OBJEXT=o, and g++ wins (it is tested later). This results in various
unexpected outcomes in further configure tests and things go downhill from
there. The actual non-zero return that causes the test to finally fail is
that 'lib' is used as the archiver without the ar-lib wrapper, which of
course bombs out.
The other tests fail for reasons we have covered on master. I think so
anyway? So, all things considered, I think we're in pretty good shape.
Cheers,
Peter