configure oddity

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?

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
[...]

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.

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?

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

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.

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

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.