bug#10565: 1 of 787 tests failed
dclarke@charon:~/build/automake-1.11.2-001$ uname -a Linux charon 2.6.32-5-powerpc64 #1 SMP Wed Jan 11 15:39:26 UTC 2012 ppc64 GNU/Linux dclarke@charon:~/build/automake-1.11.2-001$ cat /proc/version Linux version 2.6.32-5-powerpc64 (Debian 2.6.32-39squeeze1) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 11 15:39:26 UTC 2012 dclarke@charon:~/build/automake-1.11.2-001$ dclarke@charon:~/build/automake-1.11.2-001$ cat tests/test-suite.log === GNU Automake 1.11.2: tests/test-suite.log === 1 of 787 tests failed. (124 tests were not run). .. contents:: :depth: 2 SKIP: amhello-cross-compile.test (exit: 77) === /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin amhello-cross-compile: running i586-mingw32msvc-gcc --version ./defs: 381: i586-mingw32msvc-gcc: not found SKIP: ar-lib4.test (exit: 77) = /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin ar-lib4: running libtoolize --version ./defs: 381: libtoolize: not found SKIP: ar-lib5a.test (exit: 77) == /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin ar-lib5a: running lib -out:defstest.lib ./defs: 381: lib: not found ar-lib5a: skipped test: Microsoft `lib' utility not available SKIP: ar-lib6a.test (exit: 77) == /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin ar-lib6a: running libtoolize --version ./defs: 381: libtoolize: not found SKIP: ar-lib6b.test (exit: 77) == /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin ar-lib6b: running libtoolize --version ./defs: 381: libtoolize: not found SKIP: color2.test (exit: 77) /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin === Running test ./color2.test + pwd /home/dclarke/build/automake-1.11.2-001/tests/color2.dir + set -e + TERM=ansi + export TERM + red= + grn= + lgn= + blu= + std= + echo + grep . + set +e + expect -c exit 77 ./color2.test: 1: expect: not found + test 127 -eq 77 + skip_ requires a working expect program + warn_ color2: skipped test: requires a working expect program + echo color2: skipped test: requires a working expect program color2: skipped test: requires a working expect program + Exit 77 + set +e + exit 77 + exit 77 + exit_status=77 + set +e + cd /home/dclarke/build/automake-1.11.2-001/tests + test 0 != 0 + echo color2: exit 77 color2: exit 77 + exit 77 SKIP: compile4.test (exit: 77) == /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin compile4: running cl -? ./defs: 381: cl: not found SKIP: compile5.test (exit: 77) == /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin === Running test ./compile5.test + pwd /home/dclarke/build/automake-1.11.2-001/tests/compile5.dir + set -e + cp /home/dclarke/build/automake-1.11.2-001/tests/../lib/compile . + cat + chmod +x ./cl + cat + : + cat + aclocal-1.11 -Werror + autoconf -B /no/such/dir + automake-1.11 --foreign -Werror -Wall -a configure.in:4: installing `./config.guess' configure.in:4: installing `./config.sub' + ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking build system type... powerpc64-unknown-linux-gnu checking host system type... powerpc64-unknown-linux-gnu configure: creating ./config.status config.status: creating Makefile config.status: creating check_host + ./check_host + exit_status=77 + set +e + cd /home/dclarke/build/automake-1.11.2-001/tests + test 0 != 0 + echo compile5: exit 77 compile5: exit 77 + exit 77 SKIP: cond35.test (exit: 77) /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin cond35: running flex --version ./defs: 381: flex: not found SKIP: dejagnu3.test (exit: 77) == /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin dejagnu3: running runtest --version ./defs: 381: runtest: not found SKIP: dejagnu4.test (exit: 77) ==
bug#10565: 1 of 787 tests failed
Hi Dennis, thanks for the report. On 01/20/2012 06:14 PM, Dennis Clarke wrote: dclarke@charon:~/build/automake-1.11.2-001$ uname -a Linux charon 2.6.32-5-powerpc64 #1 SMP Wed Jan 11 15:39:26 UTC 2012 ppc64 GNU/Linux dclarke@charon:~/build/automake-1.11.2-001$ cat /proc/version Linux version 2.6.32-5-powerpc64 (Debian 2.6.32-39squeeze1) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 11 15:39:26 UTC 2012 dclarke@charon:~/build/automake-1.11.2-001$ === GNU Automake 1.11.2: tests/test-suite.log === 1 of 787 tests failed. (124 tests were not run). .. contents:: :depth: 2 FAIL: specflg10.test (exit: 2) == /home/dclarke/build/automake-1.11.2-001/tests:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/schily/bin specflg10: running g++ --version g++ (Debian 4.4.5-8) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. === Running test ./specflg10.test + pwd [SNIP] + make Making all in sub make[1]: Entering directory `/home/dclarke/build/automake-1.11.2-001/tests/specflg10.dir/sub' g++ -DPACKAGE_NAME=\specflg10\ -DPACKAGE_TARNAME=\specflg10\ -DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\specflg10\ 1.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\specflg10\ -DVERSION=\1.0\ -I. -I/usr/local/include -R/usr/local/lib -L/usr/local/lib -g -mcpu=970 -mtune=970 -maltivec -mabi=altivec -mvrsave -m64 -mpowerpc64 -mfull-toc -malign-power -mupdate -mcall-linux -msvr4-struct-return -pthread -MT bar.o -MD -MP -MF .deps/bar.Tpo -c -o bar.o bar.cpp mv -f .deps/bar.Tpo .deps/bar.Po g++ -R/usr/local/lib -L/usr/local/lib -g -mcpu=970 -mtune=970 -maltivec -mabi=altivec -mvrsave -m64 -mpowerpc64 -mfull-toc -malign-power -mupdate -mcall-linux -msvr4-struct-return -pthread -o bar bar.o /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.4.5/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.4.5/libstdc++.a when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.4.5/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.4.5/libstdc++.a when searching for -lstdc++ /usr/bin/ld: cannot find -lstdc++ collect2: ld returned 1 exit status make[1]: *** [bar] Error 1 make[1]: Leaving directory `/home/dclarke/build/automake-1.11.2-001/tests/specflg10.dir/sub' make: *** [all-recursive] Error 1 + exit_status=2 + set +e + cd /home/dclarke/build/automake-1.11.2-001/tests + test 0 != 0 + echo specflg10: exit 2 specflg10: exit 2 + exit 2 Do you happen to have $CFLAGS or $CXXFLAGS exported in the environment? If yes, to what values? Also, if yes, does any (or both) of the diffs below fix the issue? Thanks, Stefano -*-*- diff --git a/tests/specflg10.test b/tests/specflg10.test index efe13f5..98be12a 100755 --- a/tests/specflg10.test +++ b/tests/specflg10.test @@ -16,7 +16,6 @@ # AM_DEFAULT_SOURCE_EXT -required=g++ . ./defs || Exit 1 set -e -*-*- 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
bug#10568: automake-1.11.1 1 of 643 tests failed
severity 10568 minor severity 10565 minor retitle 10565 specflg10.test failure retitle 10568 specflg10.test failure merge 10565 10568 thanks Hi Dennis. On 01/20/2012 08:48 PM, Dennis Clarke wrote: = 1 of 643 tests failed (92 tests were not run) See tests/test-suite.log Please report to bug-automake@gnu.org = [SNIP] This fails the same test that automake 1.11.2 fails on your system: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10565 The details of the failures are basically identical (and with all likelihood due to a testsuite weakness). I'm merging the two reports now; let's continue the discussion only for the 1.11.2 failure, OK? Thanks, Stefano
bug#10555: automake: wrong use of F77FLAGS instead of FFLAGS?
Stefano Lattarini skrev 2012-01-20 20:53: On 01/19/2012 02:45 PM, Stefano Lattarini wrote: [SNIP] So, to all autoconfers: do you happen to know any reason for which Automake should use F77FLAGS? If not, I'll assume that is due to a typo or clerical mistake, and fix it (in 48 hours or so). The attached patch should take care of this. I'll push it tomorrow if there is no objection. Isn't this worthy of a NEWS entry? Or does it not affect end users at all? Cheers, Peter
Re: [PATCH 1/6] configure: search generic compilers for use in the tests
Stefano Lattarini skrev 2012-01-19 14:55:
* configure.ac: Look for generic C, C++ and Fortran compilers,
with the aim of starting to use them in the testsuite (this will
be done in future changes). This is more tricky than it seems,
since we don't want to abort the whole configure script even if
no one of those compilers is available (after all, they're only
needed by the testsuite, not to build automake), but currently
autoconf doesn't offer an easy way to obtain this behaviour.
We prefer non-GNU compilers to the GNU ones, to ensure better
coverage in the wild.
---
configure.ac | 82
+-
1 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index ddd6b2b..ea3671a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,8 +38,11 @@ AC_SUBST([am_AUTORECONF], [${AUTORECONF-autoreconf}])
AC_SUBST([am_AUTOHEADER], [${AUTOHEADER-autoheader}])
AC_SUBST([am_AUTOUPDATE], [${AUTOUPDATE-autoupdate}])
+dnl We call AC_PROG_CC in an unusual way, and only for use in our
+dnl testsuite, so also use `no-dependencies' and `no-define' among
+dnl the automake options to avoid bloating and potential problems.
AM_INIT_AUTOMAKE([1.10a dist-xz filename-length-max=99 color-tests
- parallel-tests silent-rules])
+ parallel-tests silent-rules no-define no-dependencies])
# The API version is the base version. We must guarantee
# compatibility for all releases with the same API version.
@@ -209,6 +212,83 @@ if test $am_cv_sh_errexit_works = no; then
fi
AC_SUBST([sh_errexit_works], [$am_cv_sh_errexit_works])
+
+###
+
+# Look for C, C++ and fortran compilers to be used in the testsuite.
+
+dnl We don't want to abort our configuration script if no C compiler is
+dnl available, as such a compiler is only required to run part of the
+dnl testsuite, not to build or install Automake. Ditto for C++, Fortran
+dnl and Fortran 77 compilers. Unfortunately, autoconf does not offer an
+dnl easy way to obtain this behaviour, so we'll need a few hacks.
+
+dnl We want the body of this macro to expand as a single shell statement,
+dnl thus we wrap it into { ... } brackets.
+AC_DEFUN([_AM_WRAP_MSG_ERROR], [ {
+ AC_MSG_WARN([$1])
+ am__failed=yes
+ break
+} ])
+
+AC_DEFUN([_AM_COMPILER_CAN_FAIL], [
+ m4_pushdef([AC_MSG_FAILURE], m4_defn([_AM_WRAP_MSG_ERROR]))
+ m4_pushdef([AC_MSG_ERROR], m4_defn([_AM_WRAP_MSG_ERROR]))
+ am__failed=no
+ while :; do
+ $1
+ break
+ done
+ AS_IF([test $am__failed = yes], [$2])
+ # We have to clear these cache variables, so that future checks on
+ # compilers for different languages won't be confused.
+ unset ac_cv_objext ac_cv_exeext
+ # We also need to meddle with the autoconf internals to ensure that
+ # checks to find object and executable extensions will be run anew.
+ # FIXME: In the long run, the better thing to do would be to fix
+ # FIXME: autoconf instead ...
+ m4_undefine([m4_provide(_AC_COMPILER_OBJEXT)])
+ m4_undefine([m4_provide(_AC_COMPILER_EXEEXT)])
+ m4_popdef([AC_MSG_FAILURE])
+ m4_popdef([AC_MSG_ERROR])
+])
+
+# Prefer generic compilers to GNU ones when possible. This will ensure
+# more testsuite coverage in the wild.
+# FIXME: maybe we should a more comprehensive list too look for more
+# FIXME: exotic compilers? And what about looking also for the MSVC
+# FIXME: compiler on Cygwin/MinGW systems?
+_AM_COMPILER_CAN_FAIL([AC_PROG_CC([cc gcc])], [CC=false])
Looking for MSVC on Cygwin is a definite no, IMHO. MSVC can't produce
Cygwin programs (I have never heard of it anyway, maybe with -nodefaultlib
and adding a bunch of low level cygwin stuff instead, but I highly doubt
it will fly), so it can only be viewed as a cross compiler in that
setting. IOW, the same as looking for it on Linux with Wine/binfmt-misc...
BTW, that's a good starting point for how Cygwin should be viewed when it
comes to build systems; as Linux with Wine and binfmt-misc set up to
handle PE stuff.
MinGW is another matter...
+
+# The list of C++ compilers here has been copied, pasted and edited
+# from `lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution.
+# Keep it in sync, or better again, find out a way to avoid this code
+# duplication.
+_AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl
+ [aCC CC cl.exe FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])],
+ [CXX=false])
I suppose it can be a problem that cl.exe is before g++ on Cygwin or Linux
with Wine/binfmt-misc and if MSVC is installed (and visible), when cl.exe
is best viewed as a cross compiler in those cases. But I usually don't
source my script that adds MSVC to PATH and sets up various other bits
needed in the environment when in Cygwin, so cl.exe isn't normally on my
PATH so it wouldn't be a problem *for me*. But I think there is an option
to add
Re: [PATCH 1/6] configure: search generic compilers for use in the tests
Hi Peter. On 01/20/2012 12:56 PM, Peter Rosin wrote: Stefano Lattarini skrev 2012-01-19 14:55: [MEGA-SNIP] +# Prefer generic compilers to GNU ones when possible. This will ensure +# more testsuite coverage in the wild. +# FIXME: maybe we should a more comprehensive list too look for more +# FIXME: exotic compilers? And what about looking also for the MSVC +# FIXME: compiler on Cygwin/MinGW systems? +_AM_COMPILER_CAN_FAIL([AC_PROG_CC([cc gcc])], [CC=false]) Looking for MSVC on Cygwin is a definite no, IMHO. MSVC can't produce Cygwin programs (I have never heard of it anyway, maybe with -nodefaultlib and adding a bunch of low level cygwin stuff instead, but I highly doubt it will fly), so it can only be viewed as a cross compiler in that setting. IOW, the same as looking for it on Linux with Wine/binfmt-misc... BTW, that's a good starting point for how Cygwin should be viewed when it comes to build systems; as Linux with Wine and binfmt-misc set up to handle PE stuff. MinGW is another matter... Thanks for the detailed information. I'll adjust the FIXME comment accordingly. + +# The list of C++ compilers here has been copied, pasted and edited +# from `lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution. +# Keep it in sync, or better again, find out a way to avoid this code +# duplication. +_AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl + [aCC CC cl.exe FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])], + [CXX=false]) I suppose it can be a problem that cl.exe is before g++ on Cygwin or Linux with Wine/binfmt-misc and if MSVC is installed (and visible), when cl.exe is best viewed as a cross compiler in those cases. Are you afraid that configure will, in such a setup, automatically (and erroneously) determine that we are *not* cross compiling, while in fact we are? If yes, I agree that would be problematic. Maybe we could (in a follow-up patch) avoid looking for cl.exe if we determine the current build system is Cygwin? Ugly, but easy to do (and also correct, I hope). But I usually don't source my script that adds MSVC to PATH and sets up various other bits needed in the environment when in Cygwin, so cl.exe isn't normally on my PATH so it wouldn't be a problem *for me*. But I think there is an option to add MSVC to the global environment though, and if that has been done, it might not be so easy to avoid finding MSVC from Cygwin. So the hack I have proposed above might be necessary after all. Damn. I will await confirmation from you that I have inderstood the situation correctly, before proceeding to write a patch. Thanks again for your responsiveness and support, Stefano
Re: [PATCH 1/6] configure: search generic compilers for use in the tests
Stefano Lattarini skrev 2012-01-20 15:02: Hi Peter. On 01/20/2012 12:56 PM, Peter Rosin wrote: Stefano Lattarini skrev 2012-01-19 14:55: [MEGA-SNIP] +# Prefer generic compilers to GNU ones when possible. This will ensure +# more testsuite coverage in the wild. +# FIXME: maybe we should a more comprehensive list too look for more +# FIXME: exotic compilers? And what about looking also for the MSVC +# FIXME: compiler on Cygwin/MinGW systems? +_AM_COMPILER_CAN_FAIL([AC_PROG_CC([cc gcc])], [CC=false]) Looking for MSVC on Cygwin is a definite no, IMHO. MSVC can't produce Cygwin programs (I have never heard of it anyway, maybe with -nodefaultlib and adding a bunch of low level cygwin stuff instead, but I highly doubt it will fly), so it can only be viewed as a cross compiler in that setting. IOW, the same as looking for it on Linux with Wine/binfmt-misc... BTW, that's a good starting point for how Cygwin should be viewed when it comes to build systems; as Linux with Wine and binfmt-misc set up to handle PE stuff. MinGW is another matter... Thanks for the detailed information. I'll adjust the FIXME comment accordingly. + +# The list of C++ compilers here has been copied, pasted and edited +# from `lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution. +# Keep it in sync, or better again, find out a way to avoid this code +# duplication. +_AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl + [aCC CC cl.exe FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])], + [CXX=false]) I suppose it can be a problem that cl.exe is before g++ on Cygwin or Linux with Wine/binfmt-misc and if MSVC is installed (and visible), when cl.exe is best viewed as a cross compiler in those cases. Are you afraid that configure will, in such a setup, automatically (and erroneously) determine that we are *not* cross compiling, while in fact we are? If yes, I agree that would be problematic. Maybe we could (in a follow-up patch) avoid looking for cl.exe if we determine the current build system is Cygwin? Ugly, but easy to do (and also correct, I hope). No, that's not what I'm afraid of. I'm afraid, when $host == $build, that configure will think that cl.exe is a native compiler. I mean, it's not as if it's named i686-pc-mingw32-cl.exe just because you are in a Cygwin shell, and when it is on PATH in a Cygwin setting it will produce executables that run, and I fear that configure will think the compiler is fine. So, I'm not afraid that the cross-or-not heuristic will come up with the wrong answer. I'm afraid that CC will point to a cross compiler in a native build, which would be surprising when gcc is on PATH, and probably even before cl. I believe the correct thing to do is to only look for cl when $host is the system cl produces code for. But that's very difficult, as there are cl:s that produce code for other arches (x64, Itanium). But since I think it's too hard to do this right, I don't think we should even try. But I also think that we should only look for cl if we have failed to find gcc/g++, that way we avoid that particular can of worms in the vast majority of cases. Perhaps it's as simple as moving cl.exe over to the end? But I usually don't source my script that adds MSVC to PATH and sets up various other bits needed in the environment when in Cygwin, so cl.exe isn't normally on my PATH so it wouldn't be a problem *for me*. But I think there is an option to add MSVC to the global environment though, and if that has been done, it might not be so easy to avoid finding MSVC from Cygwin. So the hack I have proposed above might be necessary after all. Damn. I will await confirmation from you that I have inderstood the situation correctly, before proceeding to write a patch. Ok. Cheers, Peter
Re: [PATCH 1/6] configure: search generic compilers for use in the tests
On 01/20/2012 06:14 PM, Peter Rosin wrote: + +# The list of C++ compilers here has been copied, pasted and edited +# from `lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution. +# Keep it in sync, or better again, find out a way to avoid this code +# duplication. +_AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl + [aCC CC cl.exe FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])], + [CXX=false]) I suppose it can be a problem that cl.exe is before g++ on Cygwin or Linux with Wine/binfmt-misc and if MSVC is installed (and visible), when cl.exe is best viewed as a cross compiler in those cases. Are you afraid that configure will, in such a setup, automatically (and erroneously) determine that we are *not* cross compiling, while in fact we are? If yes, I agree that would be problematic. Maybe we could (in a follow-up patch) avoid looking for cl.exe if we determine the current build system is Cygwin? Ugly, but easy to do (and also correct, I hope). No, that's not what I'm afraid of. I'm afraid, when $host == $build, that configure will think that cl.exe is a native compiler. I mean, it's not as if it's named i686-pc-mingw32-cl.exe just because you are in a Cygwin shell, and when it is on PATH in a Cygwin setting it will produce executables that run, and I fear that configure will think the compiler is fine. Which is true for our purposes, no? I mean, the automake testsuite makes (or at least should make) only two general assumptions about the compilers it uses: - they can build executables - if $(build_alias) == $(host_alias), they can run those executables So the scenario you're depicting shouldn't be problematic (either that or, more likely, I am still misunderstanding something). So, I'm not afraid that the cross-or-not heuristic will come up with the wrong answer. I'm afraid that CC will point to a cross compiler in a native build, which would be surprising when gcc is on PATH, and probably even before cl. But consider that the compilers are only needed for use in the automake testsuite , so it's not a problem if an inferior/unusual compiler gets selected by configure; in fact, it's a *feature*, since the whole point of this patch series is to make it easier and more automatic to run the testsuite with unusual, vendor-specific, or fringe compilers, to improve coverage of the wild. But see below. I believe the correct thing to do is to only look for cl when $host is the system cl produces code for. But that's very difficult, as there are cl:s that produce code for other arches (x64, Itanium). But since I think it's too hard to do this right, I don't think we should even try. But I also think that we should only look for cl if we have failed to find gcc/g++, Oh no -- I explicitly want to *prefer* cl.exe over gcc/g++! If you think this could be problematic on Cygwin, then we might explicitly avoid considering cl.exe on that particular system, to avoid weird or spurious failures. *OR* it occurs to me that we could simply take a step back, and avoid all the potential problems you are foreboding simply by avoiding looking for cl.exe *at all*. Instead, we will add proper advice in 'tests/README' explaining how to run the testsuite on MinGW with MSVC as C/C++ compiler. This way, we can assume the user will be knowledgeable and motivated enough to avoid common misconfigurations; more importantly, we'll avoid the risk of automatically producing such misconfigurations ourselves. WDYT? that way we avoid that particular can of worms in the vast majority of cases. Perhaps it's as simple as moving cl.exe over to the end? That would basically defy the purpose of having it there. [SNIP] Thanks, Stefano
Re: allowing users to add source files without rerunning the autotools?
Just a minor FYI and a minor question ... On 01/19/2012 09:27 PM, Nick Bowler wrote: [SNIP] What automake does for source files it knows about is just include $(DEPDIR)/srcfile.Po (apparently include is considered portable make?). It's not considered portable make. Still, it's worth noting that it works with every make implementation I usually test automake with: - GNU make (obviously) - FreeBSD 8.2 make (I'm almost sure this works with 7.x too, at least) - OpenBSD 4.6 - NetBSD 5.1 - Solaris 10 XPG 4 make - Solaris 10 CCS make - Sun Distributed Make 7.8 (2007/07/19) So maybe it is almost portable today. Does anyone know whether it works also with the vendor makes for AIX, OSF1/Tru64, IRIX, HP-UX? Regards, Stefano
Re: allowing users to add source files without rerunning the autotools?
Hi Nick. On 01/19/2012 09:27 PM, Nick Bowler wrote: [SNIP] Interestingly, if you actually stick a line exactly like the above into your Makefile.am, Automake will actually do The Right Thing™ and creates the .Po stub as if you had actually specified the source file normally. Presumably you'd be relying on totally unsupported internal behaviour of Automake in this case, though. :) If you feel like writing a complete example of how to (ab)use this feature in practice, so that a user can add source files at make time and have automatic dependency tracking work nonetheless, that would make a great addition to the automake manual and testsuite. Otherwise I'll try to cook up an example myself in the next days (no promise though). Best regards, Stefano
bug#10568: automake-1.11.1 1 of 643 tests failed
= 1 of 643 tests failed (92 tests were not run) See tests/test-suite.log Please report to bug-autom...@gnu.org = dclarke@charon:~/build$ uname -a Linux charon 2.6.32-5-powerpc64 #1 SMP Wed Jan 11 15:39:26 UTC 2012 ppc64 GNU/Linux dclarke@charon:~/build$ dclarke@charon:~/build$ cat /proc/version Linux version 2.6.32-5-powerpc64 (Debian 2.6.32-39squeeze1) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 11 15:39:26 UTC 2012 dclarke@charon:~/build$ dclarke@charon:~/build$ head /proc/meminfo MemTotal:8099924 kB MemFree: 5407780 kB Buffers: 361580 kB Cached: 2023804 kB SwapCached:0 kB Active: 1873764 kB Inactive: 540720 kB Active(anon): 31988 kB Inactive(anon): 388 kB Active(file):1841776 kB dclarke@charon:~/build$ configure was : dclarke@charon:~/build/automake-1.11.1-001$ ./configure checking build system type... powerpc64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for perl... /usr/bin/perl checking whether /usr/bin/perl supports ithreads... yes checking for tex... no checking whether autoconf is installed... yes checking whether autoconf works... yes checking whether autoconf is recent enough... yes checking whether ln works... yes checking for grep that handles long lines and -e... /usr/local/bin/grep checking for egrep... /usr/local/bin/grep -E checking for fgrep... /usr/local/bin/grep -F checking whether /bin/sh has working 'set -e' with exit trap... yes configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating lib/Automake/Makefile config.status: creating lib/Automake/tests/Makefile config.status: creating lib/Makefile config.status: creating lib/am/Makefile config.status: creating m4/Makefile config.status: creating tests/Makefile config.status: creating tests/defs config.status: creating tests/aclocal-1.11 config.status: creating tests/automake-1.11 dclarke@charon:~/build/automake-1.11.1-001$ gmake Making all in lib gmake[1]: Entering directory `/home/dclarke/build/automake-1.11.1-001/lib' Making all in Automake gmake[2]: Entering directory `/home/dclarke/build/automake-1.11.1-001/lib/Automake' Making all in . gmake[3]: Entering directory `/home/dclarke/build/automake-1.11.1-001/lib/Automake' rm -f Config.tmp Config.pm in=`echo Config.pm | sed 's/\.[^.]*$//'`; sed -e 's,[@]APIVERSION[@],1.11,g' -e 's,[@]PACKAGE[@],automake,g' -e 's,[@]PERL[@],/usr/bin/perl,g' -e 's,[@]PERL_THREADS[@],1,g' -e 's,[@]SHELL[@],/bin/bash,g' -e 's,[@]VERSION[@],1.11.1,g' -e s,[@]configure_input[@],Generated from $in.in; do not edit by hand.,g -e 's,[@]datadir[@],/usr/local/share,g' ./Config.in Config.tmp chmod +x Config.tmp chmod a-w Config.tmp mv -f Config.tmp Config.pm gmake[3]: Leaving directory `/home/dclarke/build/automake-1.11.1-001/lib/Automake' Making all in tests gmake[3]: Entering directory `/home/dclarke/build/automake-1.11.1-001/lib/Automake/tests' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/dclarke/build/automake-1.11.1-001/lib/Automake/tests' gmake[2]: Leaving directory `/home/dclarke/build/automake-1.11.1-001/lib/Automake' Making all in am gmake[2]: Entering directory `/home/dclarke/build/automake-1.11.1-001/lib/am' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/dclarke/build/automake-1.11.1-001/lib/am' gmake[2]: Entering directory `/home/dclarke/build/automake-1.11.1-001/lib' gmake[2]: Nothing to be done for `all-am'. gmake[2]: Leaving directory `/home/dclarke/build/automake-1.11.1-001/lib' gmake[1]: Leaving directory `/home/dclarke/build/automake-1.11.1-001/lib' Making all in . gmake[1]: Entering directory `/home/dclarke/build/automake-1.11.1-001' rm -f automake automake.tmp sed -e 's,[@]APIVERSION[@],1.11,g' -e 's,[@]PACKAGE[@],automake,g' -e 's,[@]PATH_SEPARATOR[@],:,g' -e 's,[@]PERL[@],/usr/bin/perl,g' -e 's,[@]PERL_THREADS[@],1,g' -e 's,[@]SHELL[@],/bin/bash,g' -e 's,[@]VERSION[@],1.11.1,g' -e 's,[@]configure_input[@],Generated from automake.in; do not edit by hand.,g' -e 's,[@]datadir[@],/usr/local/share,g' ./automake.in automake.tmp chmod +x automake.tmp chmod a-w automake.tmp mv -f automake.tmp automake rm -f aclocal aclocal.tmp sed -e 's,[@]APIVERSION[@],1.11,g' -e 's,[@]PACKAGE[@],automake,g' -e 's,[@]PATH_SEPARATOR[@],:,g' -e 's,[@]PERL[@],/usr/bin/perl,g' -e 's,[@]PERL_THREADS[@],1,g' -e 's,[@]SHELL[@],/bin/bash,g' -e 's,[@]VERSION[@],1.11.1,g' -e 's,[@]configure_input[@],Generated from aclocal.in; do not edit by hand.,g' -e 's,[@]datadir[@],/usr/local/share,g' ./aclocal.in aclocal.tmp chmod +x aclocal.tmp chmod a-w aclocal.tmp mv -f aclocal.tmp aclocal
bug#10555: automake: wrong use of F77FLAGS instead of FFLAGS?
On 01/19/2012 02:45 PM, Stefano Lattarini wrote: [SNIP] So, to all autoconfers: do you happen to know any reason for which Automake should use F77FLAGS? If not, I'll assume that is due to a typo or clerical mistake, and fix it (in 48 hours or so). The attached patch should take care of this. I'll push it tomorrow if there is no objection. Thanks, Stefano From c515aac8817b20a8f0a6ed8969f1f1d0b37c3802 Mon Sep 17 00:00:00 2001 Message-Id: c515aac8817b20a8f0a6ed8969f1f1d0b37c3802.1327089175.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri, 20 Jan 2012 20:52:02 +0100 Subject: [PATCH] fixlet: flags for Fortran77 compiler are in FFLAGS, not F77FLAGS This change fixes automake bug#10555. * lib/Automake/Variable.pm (%_ac_macro_for_var): The code generated by AC_PROG_F77 uses FFLAGS, not F77FLAGS, as the variable where to look for switches for the Fortran 77 compiler: adjust accordingly. --- lib/Automake/Variable.pm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm index 686847d..8f712bd 100644 --- a/lib/Automake/Variable.pm +++ b/lib/Automake/Variable.pm @@ -181,7 +181,7 @@ my %_ac_macro_for_var = CXX = 'AC_PROG_CXX', CXXFLAGS = 'AC_PROG_CXX', F77 = 'AC_PROG_F77', - F77FLAGS = 'AC_PROG_F77', + FFLAGS = 'AC_PROG_F77', FC = 'AC_PROG_FC', FCFLAGS = 'AC_PROG_FC', OBJC = 'AC_PROG_OBJC', -- 1.7.7.3
Re: allowing users to add source files without rerunning the autotools?
On Fri, 2012-01-20 at 20:35 +0100, Stefano Lattarini wrote: What automake does for source files it knows about is just include $(DEPDIR)/srcfile.Po (apparently include is considered portable make?). It's not considered portable make. Still, it's worth noting that it works with every make implementation I usually test automake with: FYI, I believe that POSIX has approved adding an include command to the make standard. I can't remember for sure. I know that POSIX standard != portable, necessarily, but it's a start.
Re: allowing users to add source files without rerunning the autotools?
On 2012-01-20 20:35 +0100, Stefano Lattarini wrote: Just a minor FYI and a minor question ... On 01/19/2012 09:27 PM, Nick Bowler wrote: [SNIP] What automake does for source files it knows about is just include $(DEPDIR)/srcfile.Po (apparently include is considered portable make?). It's not considered portable make. Still, it's worth noting that it works with every make implementation I usually test automake with: - GNU make (obviously) - FreeBSD 8.2 make (I'm almost sure this works with 7.x too, at least) - OpenBSD 4.6 - NetBSD 5.1 - Solaris 10 XPG 4 make - Solaris 10 CCS make - Sun Distributed Make 7.8 (2007/07/19) Interesting point. It works with dmake as well. Perhaps it can be someday included in the list of effectively portable make features (like recursive macro expansion). Does anyone know whether it works also with the vendor makes for AIX, OSF1/Tru64, IRIX, HP-UX? I'm sure someone knows, but alas that person is not me. :) Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: allowing users to add source files without rerunning the autotools?
Hi Stefano, On 2012-01-20 20:36 +0100, Stefano Lattarini wrote: On 01/19/2012 09:27 PM, Nick Bowler wrote: [SNIP] Interestingly, if you actually stick a line exactly like the above into your Makefile.am, Automake will actually do The Right Thing™ and creates the .Po stub as if you had actually specified the source file normally. Presumably you'd be relying on totally unsupported internal behaviour of Automake in this case, though. :) If you feel like writing a complete example of how to (ab)use this feature in practice, so that a user can add source files at make time and have automatic dependency tracking work nonetheless, that would make a great addition to the automake manual and testsuite. Otherwise I'll try to cook up an example myself in the next days (no promise though). When I posted that, it was just an interesting side note. I didn't think that you could use this to help with the files not known until build time problem. But now that you mention it, I think I see how it might be used for this purpose. I can certainly try to put something together, but I doubt I'll have time this weekend to do it. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: allowing users to add source files without rerunning the autotools?
On Wed, Jan 18, 2012 at 8:49 PM, Miles Bader mi...@gnu.org wrote: For cleaning non-automake-handled stuff, you can add a clean-local: rule (and maintainer-clean-local: etc) that does cleaning however you want. The automake-generated clean rule will depend on it, but you control what it does. For packaging, you can use the dist-hook: rule. CLEANFILES = ... EXTRA_DIST = I even put wildcards in there: EXTRA_DIST = dirForUserContrib/*
