bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefano Lattarini
Subject: bug#10324: [Platform-testers] Automake 1.11.1b test release
Date: Mon, 19 Dec 2011 21:06:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16

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"?

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 ;-)

Thanks,
  Stefano





reply via email to

[Prev in Thread] Current Thread [Next in Thread]