Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

[Eric Blake]

On 09/23/2015 03:37 PM, Pavel Raiskup wrote:

> 
>>From 5e8a4c5173f1aa0786e8eba15fb07bfe04b83862 Mon Sep 17 00:00:00 2001
> From: Pavel Raiskup <address@hidden>
> Date: Fri, 18 Sep 2015 23:17:07 +0200
> Subject: [PATCH] libtoolize: fix infinite recursion in m4
> 
> Some projects use this construct in configure.ac:
> 
>   m4_define([version], m4_include([version])

Missing a )

The faulty package used:

m4_define([version], m4_include(version))

and the infinite recursion occurred _because_ the usage was underquoted.
 But as you wrote things here, you have sufficient quoting that you
won't trigger infinite recursion.  You need to drop the second [] for
this to be an accurate representation of the failure.

>   pkg_version=version
> 
> When the m4_include builtin is undefined (as was done in
> libtoolize and extract-trace scripts), the call to this 'version'
> macro gone to infinite recursion (until ENOMEM).  So rather

s/gone to infinite/enters an infinite/

> re-define all potentially dangerous macros by empty strings,
> suggested by Eric Blake.
> 
> While we are on it, merge the macro-"blacklist" with similar list
> implemented in gettext, except the 'm4_esyscmd'.  It's kept

s/except the/except for/

> defined because we already trace AC_INIT macro for package
> version, while it is often specified by
> m4_esyscmd(git-version-gen).  Similarly to m4_include, m4_esyscmd
> might be opt-in-blacklisted in future.
> 
> References:
> http://lists.gnu.org/archive/html/libtool/2015-09/msg00000.html
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580
> 

With the commit message touched up, it looks okay to me.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature