Patchwork configure oddity

login
register
mail settings
Submitter Mike Stump
Date Feb. 22, 2011, 1:34 a.m.
Message ID <2082591D-43B2-4CFC-B8FE-1651137FF1AA@comcast.net>
Download mbox | patch
Permalink /patch/83902/
State New
Headers show

Comments

Mike Stump - Feb. 22, 2011, 1:34 a.m.
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?
Ralf Wildenhues - Feb. 22, 2011, 5:32 a.m.
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
[...]
Mike Stump - Feb. 22, 2011, 8:23 a.m.
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.
Pedro Alves - Feb. 22, 2011, 1:07 p.m.
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?
Jack Howarth - Feb. 22, 2011, 2:16 p.m.
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
Mike Stump - Feb. 22, 2011, 6:45 p.m.
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.
Peter O'Gorman - Feb. 22, 2011, 7:30 p.m.
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
Mike Stump - Feb. 22, 2011, 9:03 p.m.
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.

Patch

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