[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.
From: |
Eric Blake |
Subject: |
Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow. |
Date: |
Sat, 19 Sep 2015 15:05:07 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
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
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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature