10:18 p.m.
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(a)redhat.com>
To: "Jim Meyering" <jim(a)meyering.net>
Cc: libvir-list(a)redhat.com, bug-gnu-gettext(a)gnu.org, "Peter Krempa"
<pkrempa(a)redhat.com>, "bug-gnulib" <bug-gnulib(a)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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list