Eric Blake wrote: > [adding bug-gnulib] > > On 04/24/2012 06:22 AM, Eric Blake wrote: >> On 04/24/2012 03:50 AM, Peter Krempa wrote: >>> Commit c9cd419caba9effa11ca53e8696e5f6a4b424d60 added copying of the >>> makefile for translation files from gnulib. The makefile from gnulib is >>> of version 0.18 but the build configuration cretes macros from version >>> 0.17 which breaks the build with message: >>> >>> *** error: gettext infrastructure mismatch: using a Makefile.in.in from >>> gettext version 0.18 but the autoconf macros are from gettext version >>> 0.17 >>> --- >>> bootstrap.conf | 2 +- >>> configure.ac | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> NACK. RHEL 5 still uses gettext 0.17, and this breaks the build there. > > Not just RHEL 5, but RHEL 6.2 as well. > >> >> We need to fix gnulib to not force us to use gettext 0.18. I'll look >> into this. > > Here's what I'm playing with now; so far, it appears to make life happy > for libvirt with its intentional AM_GNU_GETTEXT_VERSION([0.17]). Jim, > does this look like a reasonable approach? Any suggestions before we > make it official in gnulib? Hi Eric, That change is effectively disabling the build-time check that ensures Makefile.in.in and gettext.am versions are in sync. That version comparison is definitely the problem[*], but I haven't tried using an older gettext.m4 with newer Makefile.in.in like you propose to do. I have just inspected gettext's v0.17..HEAD Makefile.in.in diffs, and don't see a problem in this particular case. I think libvirt builds will work fine with those two files mismatched. However, I remember (too well: http://bugzilla.redhat.com/523713) that using some older-still version of gettext.m4 caused a hard-to-diagnose failure when used with newer Makefile.in.in. Since it could cause trouble with other (and perhaps future) combinations of version numbers, any such disabling should remain libvirt-specific. Possible alternative: a very specific transformation that would disable the test only in the precise 0.17-vs-0.18 case, once you have confirmed it is ok. An alternative that I've always advocated, when developing on systems with build tools that are out of date, is to build and install private copies of the latest tools. This script automates that task: http://people.redhat.com/meyering/autotools-install See its --help output for a recommended way to invoke it. [*] Rather than comparing gettext version numbers, it could be comparing some version number associated with the API that covers those two files. I suppose that this API version number would change less frequently than the gettext package version number. > diff --git i/bootstrap w/bootstrap > index 5aa73cc..1cacd03 100755 > --- i/bootstrap > +++ w/bootstrap > @@ -1,6 +1,6 @@ > #! /bin/sh > # Print a version string. > -scriptversion=2012-04-19.22; # UTC > +scriptversion=2012-04-25.04; # UTC > > # Bootstrap this package from checked-out sources. > > @@ -873,7 +873,14 @@ if test $with_gettext = yes; then > } > ' po/Makevars.template >po/Makevars || exit 1 > > - cat $GNULIB_SRCDIR/build-aux/po/Makefile.in.in > po/Makefile.in.in || > exit 1 > + gettext_sed='s/^[ ]*AM_GNU_GETTEXT_VERSION(\[*\([^]]*\)\]*).*/\1/p' > + gettext_version=$(sed -n "$gettext_sed" configure.ac) > + if test -n "$gettext_version"; then > + sed "s/\(Origin:.*-\|MACRO_VERSION = > \)0\.[0-9][0-9]/\1$gettext_version/" \ > + $GNULIB_SRCDIR/build-aux/po/Makefile.in.in > po/Makefile.in.in || > exit 1 > + else > + cp $GNULIB_SRCDIR/build-aux/po/Makefile.in.in po/Makefile.in.in || > exit 1 > + fi > > if test -d runtime-po; then > # Similarly for runtime-po/Makevars, but not quite the same. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list