configure oddity

configure oddity

[Mike Stump]

So, I was regenerating configure for another patch, and discovered differences not caused by my patch.  I installed the right version of autoconf, then ran it on the virgin configure.ac file in gcc and it produced the below patch.

Ideally, I'd like Alexandre and Ralf to rerun on their systems and see if they get what I get.  If they don't, would be nice to track down why, and get that fixed.

Ok to check in?

Index: configure
===================================================================
--- configure	(revision 170335)
+++ configure	(working copy)
@@ -886,6 +886,7 @@
 with_bugurl
 enable_languages
 with_multilib_list
+with_gnu_ld
 enable_rpath
 with_libiconv_prefix
 enable_initfini_array
@@ -899,7 +900,9 @@
 enable_static
 with_pic
 enable_fast_install
+with_gnu_ld
 enable_libtool_lock
+with_gnu_ld
 with_plugin_ld
 enable_gnu_indirect_function
 enable_comdat
@@ -924,9 +927,13 @@
 CPPFLAGS
 CXX
 CXXFLAGS
+LDFLAGS
+LIBS
+CPPFLAGS
 CCC
 CPP
 CXXCPP
+CXXCPP
 GMPLIBS
 GMPINC
 PPLLIBS
@@ -17505,7 +17512,7 @@
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17508 "configure"
+#line 17515 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17611,7 +17618,7 @@
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17614 "configure"
+#line 17621 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H

Re: configure oddity

[Ralf Wildenhues]

Hello Mike,

* Mike Stump wrote on Tue, Feb 22, 2011 at 02:34:03AM CET:
> So, I was regenerating configure for another patch, and discovered
> differences not caused by my patch.  I installed the right version of
> autoconf, then ran it on the virgin configure.ac file in gcc and it
> produced the below patch.

Weird.  gcc/gcc/configure seems up to date over here.  Which m4 version
do you have installed?

It shouldn't matter, but can you 'rm -rf autom4te.cache' and rerun
autoconf then, does that make a difference?

This sounds like an m4 bug, or an autoconf --trace issue.

> Ideally, I'd like Alexandre and Ralf to rerun on their systems and see
> if they get what I get.  If they don't, would be nice to track down
> why, and get that fixed.

Right, let's do that.  Your patch adds spurious duplicate variables in
the list of user options and that of precious variables.  Neither should
be serious, as all that's done with these lists is checking whether some
passed argument is element of one of those sets.

> Ok to check in?

I'd prefer not.

Thanks,
Ralf

> --- configure	(revision 170335)
> +++ configure	(working copy)
> @@ -886,6 +886,7 @@
>  with_bugurl
>  enable_languages
>  with_multilib_list
> +with_gnu_ld
>  enable_rpath
>  with_libiconv_prefix
>  enable_initfini_array
> @@ -899,7 +900,9 @@
>  enable_static
>  with_pic
>  enable_fast_install
> +with_gnu_ld
>  enable_libtool_lock
> +with_gnu_ld
>  with_plugin_ld
>  enable_gnu_indirect_function
>  enable_comdat
> @@ -924,9 +927,13 @@
>  CPPFLAGS
>  CXX
>  CXXFLAGS
> +LDFLAGS
> +LIBS
> +CPPFLAGS
>  CCC
>  CPP
>  CXXCPP
> +CXXCPP
>  GMPLIBS
>  GMPINC
>  PPLLIBS
[...]

Re: configure oddity

[Mike Stump]

On Feb 21, 2011, at 9:32 PM, Ralf Wildenhues wrote:
> Weird.  gcc/gcc/configure seems up to date over here.  Which m4 version
> do you have installed?

1.4.6...  I installed 1.4.15, and got the same answer.  :-(

> It shouldn't matter, but can you 'rm -rf autom4te.cache' and rerun
> autoconf then, does that make a difference?

Nope.

> This sounds like an m4 bug, or an autoconf --trace issue.

:-(  Well, that's annoying.  I've not seen autoconf fail before...  well, ok, I have, but not like this.

>> Ideally, I'd like Alexandre and Ralf to rerun on their systems and see
>> if they get what I get.  If they don't, would be nice to track down
>> why, and get that fixed.
> 
> Right, let's do that.

Ok, I'll push the bug up...

> Your patch adds spurious duplicate variables

Ok, let's nix that idea...  Thanks for the sanity check.

Re: configure oddity

[Pedro Alves]

On Tuesday 22 February 2011 08:23:00, Mike Stump wrote:
> > This sounds like an m4 bug, or an autoconf --trace issue.
> 
> :-(  Well, that's annoying.  I've not seen autoconf fail before...  well, ok, I have, but not like this.

Might be a pristine FSF autoconf vs distro patched autoconf issue?

-- 
Pedro Alves

Re: configure oddity

[Mike Stump]

On Feb 22, 2011, at 5:07 AM, Pedro Alves wrote:
> On Tuesday 22 February 2011 08:23:00, Mike Stump wrote:
>>> This sounds like an m4 bug, or an autoconf --trace issue.
>> 
>> :-(  Well, that's annoying.  I've not seen autoconf fail before...  well, ok, I have, but not like this.
> 
> Might be a pristine FSF autoconf vs distro patched autoconf issue?

Nope, mine was freshly downloaded from ftp.gnu.org.

Re: configure oddity

[Peter O'Gorman]

On 02/22/2011 12:45 PM, Mike Stump wrote:
> On Feb 22, 2011, at 5:07 AM, Pedro Alves wrote:
>> On Tuesday 22 February 2011 08:23:00, Mike Stump wrote:
>>>> This sounds like an m4 bug, or an autoconf --trace issue.
>>>
>>> :-(  Well, that's annoying.  I've not seen autoconf fail before...  well, ok, I have, but not like this.
>>
>> Might be a pristine FSF autoconf vs distro patched autoconf issue?
>
> Nope, mine was freshly downloaded from ftp.gnu.org.
>

I had a quick look at this, installing m4-1.4.15 and then autoconf-2.64 
(using your new m4) will give you these differences - not only on Mac OS X.

Rebuilding autoconf-2.64 with m4-1.4.13 works. I did not try m4-1.4.14.

Peter

Re: configure oddity

[Mike Stump]

On Feb 22, 2011, at 11:30 AM, Peter O'Gorman wrote:
> I had a quick look at this, installing m4-1.4.15 and then autoconf-2.64 (using your new m4) will give you these differences - not only on Mac OS X.
> 
> Rebuilding autoconf-2.64 with m4-1.4.13 works. I did not try m4-1.4.14.

Ah, that explains it then, autoconf smelled out gm4 (unknown to me) and used it, and it was m4-1.4.15.  It chose this over m4, which was 1.4.6.  The newer m4 came from macports.

So, do we document that one needs m4-1.4.13 or older?  Ick.  Add a PREREQ line to exclude the known buggy version?  I fixed mine by rebuilding autoconf with the old m4 in the path and this fixed it.

export M4=gm4-1.4.6 before running autoconf also fixes it as well.

Thanks.

Re: configure oddity

[Ralf Wildenhues]

* Mike Stump wrote on Tue, Feb 22, 2011 at 10:03:07PM CET:
> On Feb 22, 2011, at 11:30 AM, Peter O'Gorman wrote:
> > I had a quick look at this, installing m4-1.4.15 and then autoconf-2.64 (using your new m4) will give you these differences - not only on Mac OS X.
> > 
> > Rebuilding autoconf-2.64 with m4-1.4.13 works. I did not try m4-1.4.14.
> 
> Ah, that explains it then, autoconf smelled out gm4 (unknown to me)
> and used it, and it was m4-1.4.15.  It chose this over m4, which was
> 1.4.6.  The newer m4 came from macports.
> 
> So, do we document that one needs m4-1.4.13 or older?  Ick.  Add a
> PREREQ line to exclude the known buggy version?  I fixed mine by
> rebuilding autoconf with the old m4 in the path and this fixed it.
> 
> export M4=gm4-1.4.6 before running autoconf also fixes it as well.

How about this patch to diagnose such issues early (test case taken from
gnulib)?  This way you get an error if you run autoconf, aclocal, or
automake, anywhere in GCC, and the underlying M4 has the problem.

I wouldn't mind a warning instead of a hard error either, if that's what
people prefer.

Thanks,
Ralf

Guard against M4 versions with a buggy strstr.

config/ChangeLog:
2011-02-26  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* override.m4: Error out if a buggy M4 was detected, to
	avoid spurious diffs in generated files.

diff --git a/config/override.m4 b/config/override.m4
index fc2d527..9536009 100644
--- a/config/override.m4
+++ b/config/override.m4
@@ -48,6 +48,15 @@ _GCC_AUTOCONF_VERSION_CHECK
 ])
 
 
+dnl Ensure we do not use a buggy M4.
+m4_pushdef([M], [..wi.d.])
+m4_append_uniq([M], [.d.], [])
+m4_if(M, [..wi.d.], [],
+  [m4_fatal(m4_do([m4 with buggy strstr detected.  Please install
+GNU M4 < 1.4.14 or > 1.4.15 and set the M4 environment variable]))])
+m4_popdef([M])
+
+
 dnl Fix 2.64 cross compile detection for AVR and RTEMS
 dnl by not trying to compile fopen.
 m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.64],

Re: configure oddity

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On 02/26/2011 05:07 AM, Ralf Wildenhues wrote:
> How about this patch to diagnose such issues early (test case taken from
> gnulib)?  This way you get an error if you run autoconf, aclocal, or
> automake, anywhere in GCC, and the underlying M4 has the problem.

I like the concept, although I can make it shorter.

Autoconf's m4/m4.m4 needs a similar test.

> 2011-02-26  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
> 
> 	* override.m4: Error out if a buggy M4 was detected, to
> 	avoid spurious diffs in generated files.
> 
> diff --git a/config/override.m4 b/config/override.m4
> index fc2d527..9536009 100644
> --- a/config/override.m4
> +++ b/config/override.m4
> @@ -48,6 +48,15 @@ _GCC_AUTOCONF_VERSION_CHECK
>  ])
>  
>  
> +dnl Ensure we do not use a buggy M4.

m4_if(m4_index([..wi.d.], [.d.]), [-1],
  [m4_fatal(...

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: configure oddity

[Mike Stump]

On Feb 26, 2011, at 4:07 AM, Ralf Wildenhues wrote:
> How about this patch to diagnose such issues early (test case taken from
> gnulib)?

For mere users and developers, they don't ever need to run autoconf, and so, no requirement?  I only had to as I was editing a configure.ac file, and wanted to regenerate.  Maybe we don't want to bother most uses and developers...  though, that said, I don't have the maintainer mode enable to re-generate, but instead was just running my hand, so if we conditionalize the check on the type of user, we might miss some.

Re: configure oddity

[Ralf Wildenhues]

* Mike Stump wrote on Sun, Feb 27, 2011 at 11:40:42PM CET:
> On Feb 26, 2011, at 4:07 AM, Ralf Wildenhues wrote:
> > How about this patch to diagnose such issues early (test case taken from
> > gnulib)?
> 
> For mere users and developers, they don't ever need to run autoconf,
> and so, no requirement?

Correct.  The patch doesn't change anything for users that do not run
autoconf.

> I only had to as I was editing a configure.ac
> file, and wanted to regenerate.  Maybe we don't want to bother most
> uses and developers...  though, that said, I don't have the maintainer
> mode enable to re-generate, but instead was just running my hand, so
> if we conditionalize the check on the type of user, we might miss
> some.

This patch doesn't change at all the semantics of whether you need to
run autoconf or not.  Only when you run it, no matter whether triggered
by make or run manually, it diagnoses buggy m4 versions.

More compact patch based on Eric's feedback below.

Thanks,
Ralf

Guard against M4 versions with a buggy strstr.

config/ChangeLog:
2011-02-26  Ralf Wildenhues  <...>
	    Eric Blake  <...>

	* override.m4: Error out if a buggy M4 was detected, to
	avoid spurious diffs in generated files.

diff --git a/config/override.m4 b/config/override.m4
index fc2d527..4f3b9ae 100644
--- a/config/override.m4
+++ b/config/override.m4
@@ -48,6 +48,12 @@ _GCC_AUTOCONF_VERSION_CHECK
 ])
 
 
+dnl Ensure we do not use a buggy M4.
+m4_if(m4_index([..wi.d.], [.d.]), [-1],
+  [m4_fatal(m4_do([m4 with buggy strstr detected.  Please install
+GNU M4 < 1.4.14 or > 1.4.15 and set the M4 environment variable]))])
+
+
 dnl Fix 2.64 cross compile detection for AVR and RTEMS
 dnl by not trying to compile fopen.
 m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.64],

Re: configure oddity

[Ralf Wildenhues]

[ http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01716.html ]

* Ralf Wildenhues wrote on Mon, Feb 28, 2011 at 07:38:50AM CET:
> This patch doesn't change at all the semantics of whether you need to
> run autoconf or not.  Only when you run it, no matter whether triggered
> by make or run manually, it diagnoses buggy m4 versions.

Nobody complained about the patch, so I'm committing it to GCC and
syncing to src, with recommendations updated.  If you get a runtime
failure from m4 when running any of autoconf, aclocal, or automake, in
the GCC or src trees, then that means you have a buggy m4 and should
update to a fixed version.

I am specifically _not_ testing for the other bug Eric found (see
http://lists.gnu.org/archive/html/autoconf-patches/2011-02/msg00035.html)
because we don't yet have evidence that the bug causes differing output
in practice, and I'm guessing that m4 versions with that particular bug
are so widespread that it would upset people to see their
--enable-maintainer-mode builds fail due to the check.

Thanks,
Ralf

2011-03-05  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
	    Eric Blake  <eblake@redhat.com>

	* override.m4: Error out if a buggy M4 was detected, to
	avoid spurious diffs in generated files.

diff --git a/config/override.m4 b/config/override.m4
index fc2d527..52bd1c3 100644
--- a/config/override.m4
+++ b/config/override.m4
@@ -48,6 +48,12 @@ _GCC_AUTOCONF_VERSION_CHECK
 ])
 
 
+dnl Ensure we do not use a buggy M4.
+m4_if(m4_index([..wi.d.], [.d.]), [-1],
+  [m4_fatal(m4_do([m4 with buggy strstr detected.  Please install
+GNU M4 1.4.16 or newer and set the M4 environment variable]))])
+
+
 dnl Fix 2.64 cross compile detection for AVR and RTEMS
 dnl by not trying to compile fopen.
 m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.64],

Re: configure oddity

[Jack Howarth]

On Tue, Feb 22, 2011 at 12:23:00AM -0800, Mike Stump wrote:
> On Feb 21, 2011, at 9:32 PM, Ralf Wildenhues wrote:
> > Weird.  gcc/gcc/configure seems up to date over here.  Which m4 version
> > do you have installed?
> 
> 1.4.6...  I installed 1.4.15, and got the same answer.  :-(
> 
> > It shouldn't matter, but can you 'rm -rf autom4te.cache' and rerun
> > autoconf then, does that make a difference?
> 
> Nope.
> 
> > This sounds like an m4 bug, or an autoconf --trace issue.
> 
> :-(  Well, that's annoying.  I've not seen autoconf fail before...  well, ok, I have, but not like this.
> 
> >> Ideally, I'd like Alexandre and Ralf to rerun on their systems and see
> >> if they get what I get.  If they don't, would be nice to track down
> >> why, and get that fixed.
> > 
> > Right, let's do that.
> 
> Ok, I'll push the bug up...
> 
> > Your patch adds spurious duplicate variables
> 
> Ok, let's nix that idea...  Thanks for the sanity check.

Mike,
   For what its worth, I've seen the same thing on x86_64-apple-darwin10 using
autoconf 2.64. In case it makes a difference, I don't use maintenance mode to
regenerate the configure files but instead explicitly use commands like...

cd libjava
autoconf -I. -I../config

                Jack