Re: [libvirt] [PATCH] build: Fix version of gettext macros

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.