bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warn-on-use.m4 requires modern M4?


From: Jim Meyering
Subject: Re: warn-on-use.m4 requires modern M4?
Date: Tue, 12 Jan 2010 17:12:34 +0100

Eric Blake wrote:

> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> I get errors from autoreconf when bootstrapping Libidn on a Ubuntu 8.04
>> LTS system, and removing the recent warn-on-use.m4 file fixes it.  Is
>> there something in the file that requires a recent GNU M4?  Ubuntu 8.04
>> has GNU M4 1.1.10, and according to gnulib's DEPENDENCIES 1.4.5 or later
>> should be OK.
>
> m4 1.4.6 or better is preferred (and in fact, enforced by newer autoconf), but
> yes, 1.4.5 is okay with older autoconf.
>
> The problem is not old m4, but old autoconf.  Which version are you using?
>
> Meanwhile, I can work around the problem by making sure warn-on-use.m4 defines
> enough helper macros if they are not already defined by autoconf.  I just need
> to know which helper macros weren't available.  We already guarantee
> m4_foreach_w in gnulib-common.m4, so I'm guessing that it might be AS_VAR_IF 
> or
> AS_VAR_SET.
>
> <time passes>
>
> Sure enough, we have other uses of AS_VAR_SET in gnulib, but I appear to be 
> the
> first user of AS_VAR_IF (well, warnings.m4 uses gl_AS_VAR_IF); that macro was
> only introduced in autoconf 2.63b, even though gnulib still claims to work 
> with
> as old as 2.59.
>
> So, the right patch would be to move gl_AS_VAR_IF out of warnings.m4, and make
> gnulib-common.m4 define a fallback AS_VAR_IF.  I'll take care of that.
>
> Meanwhile, based on the recent security hole in older automake, should we bite
> the bullet and require automake 1.10.3 or better (which in turn bumps the
> minimum autoconf requirement from 2.59 up to 2.60)?

That sounds worthwhile to me.
However, I'd go a little further and require
  1.10.x, 3 <= x
or
  1.11.y, 1 <= y
--------------
or maybe just exclude the buggy 1.11 release, like

  require 1.10.3, but explicitly exclude 1.11.

But that doesn't address the problem with "1.11a",
which is what I tend to use, but which may come before
or after the 1.11.1 release.

IMHO, this is a good excuse to make automake switch to
using "git describe"-based --version output.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]