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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[adding gnulib]

On 08/24/2017 12:20 PM, Erik Skultety wrote:
> Revert @f8172388c which broke the build on Centos 6, because of old
> 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).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux