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

[Pavel Raiskup]

Hi Eric, thanks for your review!

On Saturday 19 of September 2015 15:05:07 Eric Blake wrote:
> On 09/19/2015 02:09 AM, Pavel Raiskup wrote:
> > Hi Hiroyuki Sato,
> > 
> > On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote:
> >> This configure.ac is extreme slow on libtool-2.4.6.
> >> But It run smoothly on libtool-2.4.2.
> >> https://github.com/groonga/groonga/blob/master/configure.ac
> > 
> > thanks for reproducer!
> > 
> > This _really_ looks like issue mentioned [1], though the thread is
> > believed to be resolved (with existing small slowdown between
> > libtool-2.4.5 and 2.4.2).  Let me CC Robert whether this patch does not
> > actually fix the "1 sec" slowdown of libtoolize.
> 
> This looks very much like the same bug that gettext had:
> http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=d75090f2
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580

Indeed, I missed that report.

> Your proposed solution doesn't seem quite right:
> 
> >          # Disable these macros.
> >          m4_undefine([m4_dnl])
> > -        m4_undefine([m4_include])
> >          m4_undefine([m4_m4exit])
> >          m4_undefine([m4_m4wrap])
> >          m4_undefine([m4_maketemp])
> > +        # Rather do not use undefine here because people tend to define
> > +        # macros of the same name as file included in their bodies - which
> > +        # results in infinite recursion.
> > +        m4_define([m4_include], [])
> 
> I'd recommend that you use the same fix as gettext, and define ALL of
> these macros to an empty string, rather than special-casing m4_include
> as the only one that does not get undefined.

Agreed, m4_pushdef([trace_breaking_macro]) should not cause any harm.
I fixed the patch (attached).

Pavel

0001-libtoolize-fix-infinite-recursion-in-m4.patch
Description: Text Data