bug-bison
[Top][All Lists]
Advanced

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

Re: Bison 2.4.1: make install does not install mo files


From: Martin Jacobs
Subject: Re: Bison 2.4.1: make install does not install mo files
Date: Sun, 16 Aug 2009 15:45:27 +0200 (MEST)

Hi Akim,

thanks for your help.

On Sun, 16 Aug 2009, Akim Demaille wrote:

>
> Le 13 août 09 à 11:24, Martin Jacobs a écrit :
>
> > Hi,
>
> Hi!
>
> > After running make and doing make install, no mo files are
> > installed under /usr/share/locale.
> >
> > Running
> >
> >     make install DESTDIR=/var/tmp/bison-2.4.1
> >
> > in folder po or runtime-po creates this output:
> >
> > if test "bison" = "gettext-tools"; then \
> >          /bin/mkdir -p /var/tmp/bison-2.4.1/usr/share/gettext/po; \
> >          for file in Makefile.in.in remove-potcdate.sin quot.sed
> > boldquot.sed address@hidden address@hidden insert-header.sin
> > Rules-quot   Makevars.template; do \
> >            /usr/bin/install -c -m 644 ./$file \
> >                            /var/tmp/bison-2.4.1/usr/share/gettext/po/
> > $file; \
> >          done; \
> >          for file in Makevars; do \
> >            rm -f /var/tmp/bison-2.4.1/usr/share/gettext/po/$file; \
> >          done; \
> >        else \
> >          : ; \
> >        fi
> >
> > Previous version 2.3 was fine in same environment.
> >
> > Any idea?
>
> Nope :(  With the current Git version, I have this:
> ...
>
> What does
>
>       grep install-data: po/Makefile
>
> (in builddir) gives?  It should be
>
>       install-data: install-data-yes
>
> I suppose you have install-data-no.

Yes, you're right.

>
> The yes/no comes from @USE_NLS@, so I suppose you should study your
> config.log to understand why NLS (which is the pattern to look for in
> there) is false.
>

And config.log shows USE_NLS='no', so your assumption was
right. Remains the question, why? What did change between 2.3
and 2.4.x?


Now I'll try to figure out, what's behind that:

cpio version 2.3's configure.ac contains only

        # We use po/Makevars, so we need at least gettext 0.12.
        AM_GNU_GETTEXT_VERSION([0.12])

but version 2.4.x uses this:

        # We've never tested with gettext versions before 0.15, so play it safe.
        AM_GNU_GETTEXT([external], [need-formatstring-macros])
        AM_GNU_GETTEXT_VERSION([0.15])


This new macro AM_GNU_GETTEXT with option
[need-formatstring-macros] creates tests, that fail in my
environment and make configure reset USE_NLS to no.


Why do tests created by need-formatstring-macros fail? They
create a test code which necessarily fail:

        #ifndef __GNU_GETTEXT_SUPPORTED_REVISION
        #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 0 : -1)
        #endif

        typedef int array [2 * (__GNU_GETTEXT_SUPPORTED_REVISION(0) >= 1) - 1];


Argument 0 of macro __GNU_GETTEXT_SUPPORTED_REVISION is a
constant found in bison-2.4.1/m4/gettext.m4. My environment
does not know a predefined macro
__GNU_GETTEXT_SUPPORTED_REVISION. That means macro expands to
0, zero is never greater or equal 1, expression is false and
expanded to 0. That gives a negative array size and my gcc
3.4.6 terminates compilation with exactly that error.


Finally I changed configure.ac:

        AM_GNU_GETTEXT([external], [need-formatstring-macros])

reads now

        AM_GNU_GETTEXT([external], [need-ngettext])

and (after running autoreconf) everything is fine.


Thanks for you help.

Martin Jacobs




reply via email to

[Prev in Thread] Current Thread [Next in Thread]