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

[Alex Jia]

Hello Eric,
I still met this issue on latest upstream HEAD(f78024b)
when compiling libvirt:

Making all in po
make[2]: Entering directory `/home/ajia/Workspace/libvirt/po'
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18
make[2]: *** [check-macro-version] Error 1

Regards,
Alex


----- Original Message -----
From: "Eric Blake" <eblake at redhat.com>
To: "Jim Meyering" <jim at meyering.net>
Cc: libvir-list at redhat.com, bug-gnu-gettext at gnu.org, "Peter Krempa" <pkrempa at redhat.com>, "bug-gnulib" <bug-gnulib at gnu.org>
Sent: Thursday, April 26, 2012 12:45:29 AM
Subject: Re: [libvirt] [PATCH] build: Fix version of gettext macros

[adding bug-gnu-gettext]

On 04/25/2012 07:04 AM, Jim Meyering wrote:

>>>> *** error: gettext infrastructure mismatch: using a Makefile.in.in from
>>>> gettext version 0.18 but the autoconf macros are from gettext version
>>>> 0.17
>>>
>>> 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've done likewise.  In fact, it looks like the Makefile.in.in from 0.18
is _already_ taking pains to be back-compatible to an 0.17 toolchain;
witness constructs like:

> @@ -395,9 +402,15 @@
>         tmpdir=`pwd`; \
>         echo "$$lang:"; \
>         test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \
> -       echo "$${cdcmd}$(MSGMERGE) $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \
> +       echo "$${cdcmd}$(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \
>         cd $(srcdir); \
> -       if $(MSGMERGE) $$lang.po $(DOMAIN).pot -o $$tmpdir/$$lang.new.po; then \
> +       if { case `$(MSGMERGE) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
> +              '' | 0.[0-9] | 0.[0-9].* | 0.1[0-7] | 0.1[0-7].*) \
> +                $(MSGMERGE) $(MSGMERGE_OPTIONS) -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \
> +              *) \
> +                $(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \
> +            esac; \
> +          }; then \

where the 0.18 version of Makefile.in.in is catering to both msgmerge
0.17 (where lang was a positional argument) and msgmerge 0.18 (where
--lang is an option)

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

It looks like modern gettext (from 0.17 onwards) is trying to be
specifically aware of back-compat issues, at which point, the version
mismatch check is too strict (rather than requiring strict equality, you
should instead be checking for a one-way inequality - as long as the
Makefile.in.in version is the same _or newer_ than the m4 macros that
were used during configure, then it has been designed to work with the
older version of gettext hard-coded into configure).  If we can have
gettext promise to maintain this back-compat, then we can rework the
gnulib DEPENDENCIES file to specifically state gettext 0.17 or newer,
rather than its current bleeding-edge recommendation of only the latest
gettext.

> 
> [*] 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.

Precisely - it looks like as of gettext 0.17, we settled on enough of an
API that the gettext 0.18 Makefile.in.in was still able to satisfy the
needs of the 0.17 setup, once you can get past the version mismatch
error checking.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


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