Re: AC_TYPE_LONG_LONG_INT busted in current Autoconf

[Paul Eggert]

On 2024-01-16 20:57, Nick Bowler wrote:

You definitely need to also remove the ;;
on the previous lines


Oh, right, thanks! Further patch attached and installed.

I tend not to run into these problems because Gnulib overrides these 
macros. At some point we should coalesce the two.From 3a813b3b2f9f3a8ec0df95e444b6fb54267775a9 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 16 Jan 2024 21:19:31 -0800
Subject: [PATCH] Fix typo in previous patch

---
 lib/autoconf/types.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/autoconf/types.m4 b/lib/autoconf/types.m4
index d12a1dc6..8ed2f155 100644
--- a/lib/autoconf/types.m4
+++ b/lib/autoconf/types.m4
@@ -532,7 +532,7 @@ AC_DEFUN([AC_TYPE_LONG_LONG_INT],
   AC_CACHE_CHECK([for long long int], [ac_cv_type_long_long_int],
  [ac_cv_type_long_long_int=yes
   case $ac_prog_cc_stdc in
-	no | c89) ;;
+	no | c89)
 	  ac_cv_type_long_long_int=$ac_cv_type_unsigned_long_long_int
 	  if test $ac_cv_type_long_long_int = yes; then
 	dnl Catch a bug in Tandem NonStop Kernel (OSS) cc -O circa 2004.
@@ -577,7 +577,7 @@ AC_DEFUN([AC_TYPE_UNSIGNED_LONG_LONG_INT],
 [ac_cv_type_unsigned_long_long_int],
 [ac_cv_type_unsigned_long_long_int=yes
  case $ac_prog_cc_stdc in
-   no | c89) ;;
+   no | c89)
 	 AC_LINK_IFELSE(
 	   [_AC_TYPE_LONG_LONG_SNIPPET],
 	   [],
-- 
2.40.1

Re: AC_TYPE_LONG_LONG_INT busted in current Autoconf

[Nick Bowler]

On 2024-01-16 23:22, Paul Eggert wrote:
> Thanks for reporting that bug. I installed the attached on Savannah; please 
> give it a try.

I applied the patch on top of the 2.72 release.  You definitely need to also 
remove the ;;
on the previous lines, every shell I try (new and old) now barfs on the case 
statement,
e.g.,

  % ./configure   
  [...]
  checking for unsigned long long int... ./configure[3221]: syntax error at 
line 3229 : `confdefs.h' unexpected

If I remove the ;; too it seems to be working.

Thanks,
  Nick

Re: AC_TYPE_LONG_LONG_INT busted in current Autoconf

[Paul Eggert]

Thanks for reporting that bug. I installed the attached on Savannah; 
please give it a try.From e5fae45ae39f471cba5415c21d93e5bc407eb8c7 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 16 Jan 2024 20:20:06 -0800
Subject: [PATCH] =?UTF-8?q?Fix=20=E2=80=98long=20long=E2=80=99=20checks=20?=
 =?UTF-8?q?on=20ancient=20platforms?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Nick Bowler in:
https://lists.gnu.org/r/bug-autoconf/2024-01/msg00018.html
* lib/autoconf/types.m4 (AC_TYPE_LONG_LONG_INT)
(AC_TYPE_UNSIGNED_LONG_LONG_INT): Test for these
when K&R or c89, not when neither K&R nor C89.
This fixes a thinko that I introduced in
commit cdef0d2dad57f92301cb4baf782f8c24b01d5f1d
dated Wed Feb 16 01:29:40 2011 -0800.
---
 lib/autoconf/types.m4 | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/autoconf/types.m4 b/lib/autoconf/types.m4
index 205b6562..d12a1dc6 100644
--- a/lib/autoconf/types.m4
+++ b/lib/autoconf/types.m4
@@ -533,7 +533,6 @@ AC_DEFUN([AC_TYPE_LONG_LONG_INT],
  [ac_cv_type_long_long_int=yes
   case $ac_prog_cc_stdc in
 	no | c89) ;;
-	*)
 	  ac_cv_type_long_long_int=$ac_cv_type_unsigned_long_long_int
 	  if test $ac_cv_type_long_long_int = yes; then
 	dnl Catch a bug in Tandem NonStop Kernel (OSS) cc -O circa 2004.
@@ -579,7 +578,6 @@ AC_DEFUN([AC_TYPE_UNSIGNED_LONG_LONG_INT],
 [ac_cv_type_unsigned_long_long_int=yes
  case $ac_prog_cc_stdc in
no | c89) ;;
-   *)
 	 AC_LINK_IFELSE(
 	   [_AC_TYPE_LONG_LONG_SNIPPET],
 	   [],
-- 
2.40.1

AC_TYPE_LONG_LONG_INT busted in current Autoconf

[Nick Bowler]

Hi,

In recent versions of Autoconf, AC_TYPE_LONG_LONG_INT (and
AC_TYPE_UNSIGNED_LONG_LONG_INT) wrongly indicate that (unsigned) long
long is supported on compilers which actually do not support it.

Looking at the implementation of AC_TYPE_LONG_LONG_INT, it contains:

  ac_cv_type_long_long_int=yes
  case $ac_prog_cc_stdc in
  no | c89) ;;
  *) [ run compiler probes ]
  esac

which looks like it is assuming "long long" is supported for
pre-standard and C89 compilers, only actually running checks
on compilers which support newer C standards; presumably this
is the opposite of what is intended.

The failure is easy to demonstrate with gcc:

  % cat >configure.ac <<'EOF
  AC_INIT([test], [0])
  AC_PROG_CC
  AC_TYPE_LONG_LONG_INT
  AC_OUTPUT
EOF
  
  % autoconf-2.72 --force
  % ./configure CC='gcc -Werror=long-long'
  [...]
  checking for gcc -Werror=long-long option to enable C11 features... 
unsupported
  checking for gcc -Werror=long-long option to enable C99 features... 
unsupported
  checking for gcc -Werror=long-long option to enable C89 features... none 
needed
  checking for unsigned long long int... yes
  checking for long long int... yes

The last apparently working version is autoconf-2.70, but that is
because this version of autoconf has a different bug which causes it to
believe C89 compilers support C99 (so the long long test is run in this
version).  The last actually working version is autoconf-2.69:

  % autoconf-2.69 --force
  % ./configure CC='gcc -Werror=long-long'
  [...]
  checking for gcc -Werror=long-long option to accept ISO C89... none needed
  checking for unsigned long long int... no
  checking for long long int... no

Cheers,
  Nick

[sr #111007] autoconf 2.72 warning: file 'version.m4' included several times

[Zack Weinberg]

Update of sr#111007 (group autoconf):

Priority:   5 - Unprioritized => 8 - Release N (Blocker)

___

Follow-up Comment #3:

Introducing an annoying, spurious warning on code recommended by the automake
manual does seem important enough that it should be fixed in the very next
release, but bad warning messages by themselves never rise to the level of a
*critical* problem.  Are you saying that you're not getting your own
version.m4 anymore when you do `m4_include([version.m4])` ?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/