Hi, verifying file bison-2.4.1.tar.bz2 using bison-2.4.1.tar.bz2.sig gpg mentions that key F125BDF3 is expired. Regards Martin Jacobs -- -- Dipl-Ing. Martin Jacobs * Windsbach * martin.jacobs <at> arcor.de und martin.jacobs <at> an-netz.de * ICQ:153921785 Registered Linux User #87175, http://counter.li.org/
Hi, compilatopn and tests run fine (except java tests). My environment is Linux, based on SuSE 8.1, tools are: - gcc is 3.4.6 - m4 1.4.13 - automake 1.11 - autoconf 2.63 - make (GNU) 3.81 - gettext 0.17 it makes no difference if I do first an autoreconf or use configure out of tarball. Configure command is: ./configure --target i586-suse-linux --host i586-suse-linux-gnu --build i586-suse-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info 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:(Continue reading)
Hello, We have our application server running on SOLARIS and the installed version of bison works perfectly fine. As a part of infrastructure change, we are migrating to linux and when I try to run bison in the same sub-directory, I get some weird errors (PATH prepending), which I think should not have come. I don't know much about bison, can anyone throw some light on the errors below please? Errors: /usr/bin/bison -y --d --skeleton=/home/gptsdev/bison-1.29.i386/share/bison/bison.simple bc.y && mv y.tab.c bc.c bc.y:58.26: warning: stray `,' treated as white space bc.y:58.32: warning: stray `,' treated as white space bc.y:58.38: warning: stray `,' treated as white space bc.y:58.48: warning: stray `,' treated as white space bc.y:58.55: warning: stray `,' treated as white space conflicts: 1 shift/reduce /usr/bin/m4: */usr/share/bison//home/gptsdev/bison-1.29.i386/share/bison/bison.simple: No such file or directory ******** Why is the path /usr/share/bison being preprended to my skeleton file? * NONE:0: error: m4_divert_pop(0): diversion mismatch: /usr/share/bison/c.m4:1: m4_divert: -1 stdin:1553: m4_divert_push: 0(Continue reading)
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 en <at> quot.header en <at> 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 \ > : ; \(Continue reading)
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 en <at> quot.header en <at> 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; \(Continue reading)
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: >(Continue reading)
Hi Akim and Martin,
> > 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.
This is understandable: If the programmer tells gettext "I need the
support for <inttypes.h> formatstring macros" and the system does not
have this support, i18n gets disabled. When i18n is disabled, there is
no need to install *.gmo files since they won't be used.
So the question is: Is 'need-formatstring-macros' an appropriate
requirement?
LC_ALL=C grep -r 'PRI[diouxX]' . 2>/dev/null
finds no matches in the bison source, nor any relevant matches in the
gnulib source. The commit message in [1] says:
"(AM_GNU_GETTEXT): Add; require formatstring macros since that's
the pickiest."
So I think Paul Eggert added this only because he wanted on the safe
side. (Paul Eggert *always* wants to be on the safe side.)
If 'need-ngettext' an appropriate requirement? Yes, since
src/conflicts.c
uses the ngettext function.
> > Finally I changed configure.ac:
> >
> > AM_GNU_GETTEXT([external], [need-formatstring-macros])
> >
> > reads now
(Continue reading)
Hi Bruno, many thanks for your detailed explanation. It's always a pleasure to read answers from people with in-depth knowledge, really. On Sun, 16 Aug 2009, Bruno Haible wrote: > Hi Akim and Martin, > > > > 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. > > This is understandable: If the programmer tells gettext "I need the > support for <inttypes.h> formatstring macros" and the system does not > have this support, i18n gets disabled. When i18n is disabled, there is > no need to install *.gmo files since they won't be used. > > So the question is: Is 'need-formatstring-macros' an appropriate > requirement? > LC_ALL=C grep -r 'PRI[diouxX]' . 2>/dev/null > finds no matches in the bison source, nor any relevant matches in the > gnulib source. The commit message in [1] says: > "(AM_GNU_GETTEXT): Add; require formatstring macros since that's > the pickiest." > So I think Paul Eggert added this only because he wanted on the safe > side. (Paul Eggert *always* wants to be on the safe side.) > > If 'need-ngettext' an appropriate requirement? Yes, since(Continue reading)
Le 16 août 09 à 23:36, Bruno Haible a écrit : > Hi Akim and Martin, Hi Bruno, >>> 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. > > This is understandable: If the programmer tells gettext "I need the > support for <inttypes.h> formatstring macros" and the system does not > have this support, i18n gets disabled. Ha, thanks! I thought it was related to xgettext. >>> Finally I changed configure.ac: >>> >>> AM_GNU_GETTEXT([external], [need-formatstring-macros]) >>> >>> reads now >>> >>> AM_GNU_GETTEXT([external], [need-ngettext]) > > I think this is safe to do, and will solve the problem. Thanks for your analysis and cure. >> AM_GNU_GETTEXT_VERSION([0.15])(Continue reading)
Akim Demaille wrote:
> I installed the following in 2.4.2, 2.5, and master.
OK.
> >> AM_GNU_GETTEXT_VERSION([0.15])
> >
> > This version has a different meaning: it tells which macros
> > (intl.m4 etc.) you want to include in your release tarball.
>
> Our bootstrap.conf prevents their distribution (same commit).
gettext.m4, intlmacosx.m4 etc. are included in the distribution,
fortunately. (Omitting .m4 files required to build the configure
file, other than GNU automake ones, would be seen as a bug.)
But they are omitted from the version control, which is fine -
this is precisely what AM_GNU_GETTEXT_VERSION is for.
Nonetheless, you may at some point switch to 0.17, by
1) installing gettext 0.17 yourself,
2) invoking gettexize from that version. It will change
the line to
AM_GNU_GETTEXT_VERSION([0.17])
I say this because bison is also using gnulib, and I guarantee
that there are no conflicts between the latest gnulib and the
latest released gettext (0.17 at this moment), but I don't guarantee
the absence of conflicts between the newest gnulib and older
gettext releases.
Bruno
(Continue reading)
RSS Feed8 | |
|---|---|
143 | |
1 | |
6 | |
13 | |
4 | |
8 | |
13 | |
28 | |
7 | |
8 | |
5 | |
21 | |
4 | |
1 | |
17 | |
2 | |
3 | |
9 | |
7 | |
4 | |
37 | |
35 | |
34 | |
22 | |
9 | |
5 | |
3 | |
15 | |
20 | |
28 | |
10 | |
7 | |
9 | |
11 | |
15 | |
6 | |
7 | |
58 | |
5 | |
3 | |
9 | |
28 | |
5 | |
6 | |
49 | |
7 | |
8 | |
17 | |
6 | |
17 | |
12 | |
1 | |
28 | |
36 | |
11 | |
13 | |
14 | |
5 | |
41 | |
16 | |
5 | |
5 | |
11 | |
21 | |
11 | |
29 | |
19 | |
61 | |
25 | |
14 | |
60 | |
69 | |
77 | |
22 | |
81 | |
32 | |
10 | |
66 | |
43 | |
79 | |
80 | |
57 | |
13 | |
103 | |
77 | |
17 | |
17 | |
14 | |
23 | |
27 | |
27 | |
51 | |
35 | |
32 | |
26 | |
18 | |
12 | |
23 | |
61 | |
15 | |
6 | |
30 | |
21 | |
50 | |
49 | |
50 | |
49 | |
93 | |
32 | |
125 | |
151 | |
30 | |
29 | |
33 | |
26 | |
67 | |
78 | |
6 |
