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

[Akim Demaille]

Hi Martin,

Well, we have a problem in our use of GNU Gettext, and I don't know  
what we should do.  Gettext guys, I have left all the context below,  
thanks for any help!

So we need to specify

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

because, we, developers, need this feature to generate the po files  
using a recent Gettext.  But we ship the compiled *.gmo files, which,  
I believe, are enough to install on any system.  So it is also my  
understanding that you don't need that Gettext to use the files.  So  
it should disable po files extraction in your environment, but I don't  
think it should prevent the installation of the mo files.

Am I right?

Thanks in advance.

Le 16 août 09 à 15:45, Martin Jacobs a écrit :

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 e...@quot.header e...@boldquot.header 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:

bison 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