On 08/24/2017 02:36 PM, Bruno Haible wrote: > [trimming extra CCs] > > Hi Eric, > >> Where looking through autoconf history, was indeed something that >> autoconf fixed in commit 9f28c6e (autoconf 2.63b) (CentOS 6 is still >> stuck on the older autoconf 2.63). >> https://lists.gnu.org/archive/html/autoconf-patches/2009-01/msg00051.html >> >> Sadly, I didn't quickly find a workaround in the archives for how to NOT >> trace a macro whose name is problematic > > You can modify m4/manywarnings.m4: > > 1) rename > AC_DEFUN([gl_MANYWARN_ALL_GCC(C)], > to > AC_DEFUN([gl_MANYWARN_ALL_GCC__C],
Not as elegant as autoconf's internals, but looks like it will do the trick. I'll play with it in the context of libvirt, since that's where I have a known reproducer, and with any luck, will push something to gnulib later today. > > 2) rename > AC_DEFUN([gl_MANYWARN_ALL_GCC(C++)], > to > AC_DEFUN([gl_MANYWARN_ALL_GCC__CXX], > > 3) modify line 39 > _AC_LANG_DISPATCH([$0], _AC_LANG, $@) > to make an indirection to [gl_MANYWARN_ALL_GCC__]_AC_LANG_PREFIX > > I was working with this naming scheme in a draft patch. It is not as elegant > as the current one, but should work around against said bug (if I have > understood it correctly). Yes, the bug is entirely in the fact that older autoconf did not properly shell-quote macro names to be traced, limiting the use of any macro that aclocal must find to those that are named without shell metacharacters. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature