On 09/23/2015 03:37 PM, Pavel Raiskup wrote: > >>From 5e8a4c5173f1aa0786e8eba15fb07bfe04b83862 Mon Sep 17 00:00:00 2001 > From: Pavel Raiskup <prais...@redhat.com> > 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