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: Stefano Lattarini <stefano.lattarini <at> gmail.com> Cc: Bruno Haible <bruno <at> clisp.org>, 10324 <at> debbugs.gnu.org Subject: 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.