Patchwork configure oddity

login
register
mail settings
Submitter Ralf Wildenhues
Date Feb. 26, 2011, 12:07 p.m.
Message ID <20110226120740.GE15829@gmx.de>
Download mbox | patch
Permalink /patch/84642/
State New
Headers show

Comments

Ralf Wildenhues - Feb. 26, 2011, 12:07 p.m.
* 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.
Eric Blake - Feb. 26, 2011, 2:02 p.m.
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(...
Mike Stump - Feb. 27, 2011, 10:40 p.m.
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.

Patch

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],