Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
[ apologies for the resend ] [ this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389558 ] Hello, * IOhannes m zmoelnig wrote on Wed, Sep 27, 2006 at 12:14:01PM CEST: Ralf Wildenhues wrote: Could you show the package, configure invocation and output where you are experiencing this with, so we can decide which of the above is the case? i just noticed that the actual line throwing the error is: if test $ac_cv_c_compiler_gnu = yes; then after that it was simple to find the real source of troubles: i use autoconf/configure to configure a c++-application, so i only use AC_PROG_CXX (and not AC_PROG_CC !) before calling AC_PROG_GCC_TRADITIONAL (which i do for historical reasons...) Well, then you can just remove that call of AC_PROG_GCC_TRADITIONAL. First, with Autoconf-2.60, this macro is obsoleted anyway, then it was ever only needed for dysfunctional `ioctl', see the manual: | -- Macro: AC_PROG_GCC_TRADITIONAL | Add `-traditional' to output variable `CC' if using the GNU C | compiler and `ioctl' does not work properly without | `-traditional'. That usually happens when the fixed header files | have not been installed on an old system. | | This macro is obsolescent, since current versions of the GNU C | compiler fix the header files automatically when installed. and I bet you're not going to need that anyway in your C++-only code. since ac_cv_c_compiler_gnu is obviously not set by AC_PROG_CXX (but only by AC_PROG_CC), i get the following error (which was missing in the initial report): ./configure: line 3177: test: =: unary operator expected But lastly, you may have a point, however small the relevance should be: AC_PROG_GCC_TRADITIONAL should require AC_PROG_CC. The error may be reproduced with this configure.ac script: AC_INIT AC_PROG_CXX AC_LANG(C++) AC_PROG_GCC_TRADITIONAL Autoconf folks: OK to apply? Alternatively, how about if we just tag the macro with a AC_DIAGNOSE([obsolete], ...)? Cheers, Ralf * lib/autoconf/c.m4 (AC_PROG_GCC_TRADITIONAL): Require AC_PROG_CC. Report by IOhannes m zmoelnig [EMAIL PROTECTED]. Index: lib/autoconf/c.m4 === RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v retrieving revision 1.236 diff -u -r1.236 c.m4 --- lib/autoconf/c.m4 6 Oct 2006 17:43:55 - 1.236 +++ lib/autoconf/c.m4 11 Oct 2006 19:56:45 - @@ -611,7 +611,8 @@ # --- AN_FUNCTION([ioctl], [AC_PROG_GCC_TRADITIONAL]) AC_DEFUN([AC_PROG_GCC_TRADITIONAL], -[if test $ac_cv_c_compiler_gnu = yes; then +[AC_REQUIRE([AC_PROG_CC])dnl +if test $ac_cv_c_compiler_gnu = yes; then AC_CACHE_CHECK(whether $CC needs -traditional, ac_cv_prog_gcc_traditional, [ ac_pattern=Autoconf.*'x' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
Ralf Wildenhues [EMAIL PROTECTED] writes: Autoconf folks: OK to apply? Alternatively, how about if we just tag the macro with a AC_DIAGNOSE([obsolete], ...)? For now I'd rather that you just apply the patch you sent; thanks. I'd like to defer to later the issue of actually issuing diagnostics for these obsolescent macros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
hi Ralf Wildenhues wrote: after that it was simple to find the real source of troubles: i use autoconf/configure to configure a c++-application, so i only use AC_PROG_CXX (and not AC_PROG_CC !) before calling AC_PROG_GCC_TRADITIONAL (which i do for historical reasons...) Well, then you can just remove that call of AC_PROG_GCC_TRADITIONAL. First, with Autoconf-2.60, this macro is obsoleted anyway, then it was ever only needed for dysfunctional `ioctl', see the manual: actually i did remove the call of AC_PROG_GCC_TRADITIONAL as soon as i found out what the culprit was. But lastly, you may have a point, however small the relevance should be: AC_PROG_GCC_TRADITIONAL should require AC_PROG_CC. The error may be exactly. all the best. madf.adr IOhannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
* Paul Eggert wrote on Thu, Oct 12, 2006 at 09:45:56AM CEST: Ralf Wildenhues [EMAIL PROTECTED] writes: Autoconf folks: OK to apply? Alternatively, [...] For now I'd rather that you just apply the patch you sent; thanks. Done. Thanks! Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
[ this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389558 ] Hello, * IOhannes m zmoelnig wrote on Wed, Sep 27, 2006 at 12:14:01PM CEST: Ralf Wildenhues wrote: Could you show the package, configure invocation and output where you are experiencing this with, so we can decide which of the above is the case? i just noticed that the actual line throwing the error is: if test $ac_cv_c_compiler_gnu = yes; then after that it was simple to find the real source of troubles: i use autoconf/configure to configure a c++-application, so i only use AC_PROG_CXX (and not AC_PROG_CC !) before calling AC_PROG_GCC_TRADITIONAL (which i do for historical reasons...) Well, then you can just remove that call of AC_PROG_GCC_TRADITIONAL. First, with Autoconf-2.60, this macro is obsoleted anyway, then it was ever only needed for dysfunctional `ioctl', see the manual: | -- Macro: AC_PROG_GCC_TRADITIONAL | Add `-traditional' to output variable `CC' if using the GNU C | compiler and `ioctl' does not work properly without | `-traditional'. That usually happens when the fixed header files | have not been installed on an old system. | | This macro is obsolescent, since current versions of the GNU C | compiler fix the header files automatically when installed. and I bet you're not going to need that anyway in your C++-only code. since ac_cv_c_compiler_gnu is obviously not set by AC_PROG_CXX (but only by AC_PROG_CC), i get the following error (which was missing in the initial report): ./configure: line 3177: test: =: unary operator expected But lastly, you may have a point, however small the relevance should be: AC_PROG_GCC_TRADITIONAL should require AC_PROG_CC. The error may be reproduced with this configure.ac script: AC_INIT AC_PROG_CXX AC_LANG(C++) AC_PROG_GCC_TRADITIONAL Autoconf folks: OK to apply? Alternatively, how about if we just tag the macro with a AC_DIAGNOSE([obsolete], ...)? Cheers, Ralf * lib/autoconf/c.m4 (AC_PROG_GCC_TRADITIONAL): Require AC_PROG_CC. Report by IOhannes m zmoelnig [EMAIL PROTECTED]. Index: lib/autoconf/c.m4 === RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v retrieving revision 1.236 diff -u -r1.236 c.m4 --- lib/autoconf/c.m4 6 Oct 2006 17:43:55 - 1.236 +++ lib/autoconf/c.m4 11 Oct 2006 19:56:45 - @@ -611,7 +611,8 @@ # --- AN_FUNCTION([ioctl], [AC_PROG_GCC_TRADITIONAL]) AC_DEFUN([AC_PROG_GCC_TRADITIONAL], -[if test $ac_cv_c_compiler_gnu = yes; then +[AC_REQUIRE([AC_PROG_CC])dnl +if test $ac_cv_c_compiler_gnu = yes; then AC_CACHE_CHECK(whether $CC needs -traditional, ac_cv_prog_gcc_traditional, [ ac_pattern=Autoconf.*'x' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
Ralf Wildenhues wrote: Could you show the package, configure invocation and output where you are experiencing this with, so we can decide which of the above is the case? hi Ralf. i just noticed that the actual line throwing the error is: if test $ac_cv_c_compiler_gnu = yes; then after that it was simple to find the real source of troubles: i use autoconf/configure to configure a c++-application, so i only use AC_PROG_CXX (and not AC_PROG_CC !) before calling AC_PROG_GCC_TRADITIONAL (which i do for historical reasons...) since ac_cv_c_compiler_gnu is obviously not set by AC_PROG_CXX (but only by AC_PROG_CC), i get the following error (which was missing in the initial report): ./configure: line 3177: test: =: unary operator expected so i guess AC_PROG_GCC_TRADITIONAL should AC_REQUIRE([AC_PROG_CC]) or similar. mfg.asdr. IOhannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
Hello IOhannes, Thanks for the report. * IOhannes m zmoelnig wrote on Tue, Sep 26, 2006 at 02:22:07PM CEST: Package: autoconf Version: 2.60a-3 Severity: normal AC_PROG_GCC_TRADITIONAL tests if $ac_cv_prog_gcc_traditional is set to yes or no; if ac_cv_prog_gcc_traditional is not set, then the comparision yields an error. the (expanded) shell code looks like: if test $ac_cv_prog_gcc_traditional = no; then Well. The code before the test should ensure that the variable _is_ set in all cases. In light of this, omitting the double-quotes is a nice test to see that the code is doing something wrong, or is being mis-used, or something else is unexpectedly wrong. Could you show the package, configure invocation and output where you are experiencing this with, so we can decide which of the above is the case? Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389558: autoconf: AC_PROG_GCC_TRADITIONAL throws error in comparision
Package: autoconf Version: 2.60a-3 Severity: normal AC_PROG_GCC_TRADITIONAL tests if $ac_cv_prog_gcc_traditional is set to yes or no; if ac_cv_prog_gcc_traditional is not set, then the comparision yields an error. the (expanded) shell code looks like: if test $ac_cv_prog_gcc_traditional = no; then while it really should look more like if test x$ac_cv_prog_gcc_traditional = xno; then this occurs 2 times (once with no, once with yes) mf.adr IOhannes -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages autoconf depends on: ii debianutils 2.17 Miscellaneous utilities specific t ii m41.4.4-1a macro processing language ii perl 5.8.8-6.1 Larry Wall's Practical Extraction Versions of packages autoconf recommends: ii automake1.8 [automaken] 1.8.5+nogfdl-1 A tool for generating GNU Standard ii automake1.9 [automaken] 1.9.6+nogfdl-2 A tool for generating GNU Standard -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
