libtoolize: fix infinite recursion in m4

Some projects use this construct in configure.ac:

  m4_define([version], m4_include([version]))
  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 enters an infinite recursion (until ENOMEM).  So rather
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 for 'm4_esyscmd'.  It's kept
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

* gl/build-aux/extract-trace (_G_mini): Redefine trace-breaking
macros to empty strings rather than undefining those.  Use 'dnl'
for comments.
* bootstrap: Likewise, sync with extract-trace.
* NEWS: Document.
* NO-THANKS: Mention Hiroyuki Sato.

Signed-off-by: Pavel Raiskup <praiskup@redhat.com>

1 files changed, 4 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index c5c9023c..82dd037c 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,10 @@ NEWS - list of user-visible changes between releases of GNU Libtool
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
+** Bug fixes:
+
+  - Fix significant slowdown of libtoolize for certain projects (regression
+    introduced in 2.4.3 release) caused by infinite m4 macro recursion.
 
 * Noteworthy changes in release 2.4.6 (2015-02-15) [stable]