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

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

 



On Wed, Apr 25, 2012 at 03:04:05PM +0200, Jim Meyering wrote:
> 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.

Why is gnulib trying to force a particular po/Makefile.in.in version
onto apps ? We declared what gettext we want to use, so we should
just be using the Makefile.in.in that comes with that version, not
any other version.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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