[libvirt] [PATCH] Revert "maint: Update to latest gnulib"

[Eric Blake]

[adding gnulib]

autoconf (< 2.63b) not properly quoting arguments for shell.
---
So, the last working commit is cbc700208, but I didn't want to revert to that
one directly, since I'd like to poke gnulib about the issue first and find a
proper solution.

To make sure I'm understanding, the issue is that the new
[gl_MANYWARN_ALL_GCC(C)] macro added in gnulib commit 461664a6 doesn't
play nicely with older autoconf's implementation for getting autom4te to
do tracing, with the following effect on the libvirt build:

./bootstrap: .gnulib/gnulib-tool --import --no-changelog --aux-dir
build-aux --doc-base doc --lib libgnu --m4-base m4/ --source-base
gnulib/lib/ --tests-base gnulib/tests --local-dir gnulib/local --lgpl=2
--with-tests --makefile-name=gnulib.mk --avoid=pt_chown
--avoid=lock-tests --libtool --import ...
...
autoreconf: running: aclocal --force -I m4
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `/usr/bin/m4 --nesting-limit=1024
--include=/usr/share/autoconf --debug=aflq --fatal-warning
--debugfile=autom4te.cache/traces.122t --trace=AB_INIT --trace=AC_ ....
--trace=gl_MANYWARN_ALL_GCC --trace=gl_MANYWARN_ALL_GCC(C)
--trace=gl_MANYWARN_COMPLEMENT .... m4/wcrtomb.m4 m4/wctob.m4
m4/wctomb.m4 m4/wctype_h.m4 m4/wint_t.m4 m4/write.m4 m4/xalloc.m4
m4/xsize.m4 configure.ac > autom4te.cache/output.122t'
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
./bootstrap: autoreconf failed

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; it may be as simple as avoiding
AC_DEFUN for the tricky macro name (using lower-level primitives to
define the macro but NOT trace it during aclocal, then compensating to
make sure aclocal still pulls in the right .m4 files based on something
else that is traceable).

[Bruno Haible]

[trimming extra CCs]

Hi Eric,

Post by Eric Blake
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],

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).

Bruno

[Eric Blake]

Post by Bruno Haible
[trimming extra CCs]
Hi Eric,

Post by Eric Blake
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

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.

Post by Bruno Haible
2) rename
AC_DEFUN([gl_MANYWARN_ALL_GCC(C++)],
to
AC_DEFUN([gl_MANYWARN_ALL_GCC__CXX],
3) modify line 39
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.