headers
Paul Eggert | 2 Feb 23:20
Favicon

Re: problem compiling bison 2.1

Jon Schewe <jon.schewe <at> honeywell.com> writes:

> I'm attempting to compile bision 2.1 on solaris 2.6 and finding that the
> Makefile appears to refer to src/bison to build src/bison.  Can someone
> explain what's supposed to be happening here?

That part is already supposed to be done for you: that is, the
distribution contains parse-gram.h and parse-gram.c that is newer than
parse-gram.y, so the rule should not trigger.

Perhaps you modified the time stamps of those three files?  If so,
please re-extract the distribution and get the proper time stamps.
Permalink | Reply | 1 comment |
headers
Jon Schewe | 2 Feb 23:24
Picon
Favicon

Re: problem compiling bison 2.1

On Thu, 2006-02-02 at 14:20 -0800, Paul Eggert wrote:
> Jon Schewe <jon.schewe <at> honeywell.com> writes:
> 
> > I'm attempting to compile bision 2.1 on solaris 2.6 and finding that the
> > Makefile appears to refer to src/bison to build src/bison.  Can someone
> > explain what's supposed to be happening here?
> 
> That part is already supposed to be done for you: that is, the
> distribution contains parse-gram.h and parse-gram.c that is newer than
> parse-gram.y, so the rule should not trigger.
> 
> Perhaps you modified the time stamps of those three files?  If so,
> please re-extract the distribution and get the proper time stamps.
I had done a cp -r on the directory.  I fixed that by doing a cp -r -d.
Thanks.

________________________________________________________________________
http://lug.htc.honeywell.com/people/jschewe [Honeywell Intranet Only]
*My views may not represent those of my employers
Attachment (smime.p7s): application/x-pkcs7-signature, 4339 bytes
Permalink | Reply | 0 comments |
headers
Akim Demaille | 6 Feb 14:59
Picon
Picon
Picon
Gravatar

distcheck fails because of gettext


Maybe this issue is known, maybe my set up is fishy, but:

Making uninstall in po
make[2]: Entering directory `/home/akim/src/bison/_build/bison-2.1a/_build/po'
catalogs='da.gmo de.gmo es.gmo et.gmo fr.gmo ga.gmo hr.gmo id.gmo it.gmo ja.gmo ms.gmo nb.gmo nl.gmo
pl.gmo pt_BR.gmo ro.gmo ru.gmo rw.gmo sv.gmo tr.gmo vi.gmo'; \
        for cat in $catalogs; do \
          cat=`basename $cat`; \
          lang=`echo $cat | sed -e 's/\.gmo$//'`; \
          for lc in LC_MESSAGES ; do \
            rm -f /locale/$lang/$lc/bison.mo; \
          done; \
        done
rm: cannot remove `/locale/da/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/de/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/es/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/et/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/fr/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/ga/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/hr/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/id/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/it/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/ja/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/ms/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/nb/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/nl/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/pl/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/pt_BR/LC_MESSAGES/bison.mo': Permission denied
rm: cannot remove `/locale/ro/LC_MESSAGES/bison.mo': Permission denied
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Eggert | 6 Feb 19:15
Favicon

Re: distcheck fails because of gettext

Akim Demaille <akim <at> lrde.epita.fr> writes:

> Anybody else observing this?

I'm not.

It could well be your Autoconf/Automake versions.  I am using Autoconf
2.59 (Debian stable) and Automake 1.9.6 (which I installed).

> It seems connected to this Makefile snippet:
>
>   prefix = /home/akim/src/bison/_build/bison-2.1a/_inst
>   exec_prefix = ${prefix}
>   datadir = ${datarootdir}
>   localedir = $(datadir)/locale
>   gettextsrcdir = $(datadir)/gettext/po
>
> datarootdir is not defined.

My po/Makefile looks like this:

prefix = /tmp/prefix
exec_prefix = ${prefix}
datadir = ${prefix}/share
localedir = $(datadir)/locale
gettextsrcdir = $(datadir)/gettext/po

No datarootdir there.

> ISTR that this is one of the tasks of the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akim Demaille | 7 Feb 09:14
Picon
Picon
Picon
Gravatar

Re: distcheck fails because of gettext

>>> "Paul" == Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

 > It could well be your Autoconf/Automake versions.  I am using Autoconf
 > 2.59 (Debian stable) and Automake 1.9.6 (which I installed).

OK, thanks.  Using ./configure AUTOCONF=/usr/bin/autoconf2.50
AUTOMAKE=/usr/bin/automake-1.9 made it work properly.  I guess I
updated either autoconf or automake and don't remember it.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 9 Feb 01:48
Favicon

Re: too many warnings from Bison CVS for Pike

haberg <at> math.su.se writes:

> I guess that if there is, as Akim says, a dedicated effort for the C- 
> parser to compile under C++ in current and upcoming Bison versions,  

That's not clear to me.  yacc.c happens to work, but I'd be surprised
if the yacc.c code actually conforms to the current C++ standard, and
thus there are no guarantees.  I don't recommend this usage, and I'd
rather not document it.  People who misuse C++ compilers as if they
were C compilers tend to know about the issues involved; but it's on
them to get this to work, and it's their responsibility if it doesn't.

>> Not if the compiler #defines __cplusplus.  So it's not a problem for
>> C++ compilers.
>
> I do not see what you have in your mind here.

If a compiler defines __cplusplus, then yacc.c by default never calls
memcpy, so there should never be a correctness issue about bypassing
user-defined C++ assignment operators.  There is a way to override
this, but it's not documented and nobody should use it unless they
really know what they're doing, and (again) it's on them to get it to
work.  For details, please see data/yacc.c; for an example, see
src/parse-gram.c.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 11 Feb 07:38
Favicon

Re: too many warnings from Bison CVS for Pike

haberg <at> math.su.se writes:

> Dynamic C-parserstack. This is what is Bison implements if  
> __cplusplus is not defined. However, this should work under C++ as  
> well

Implementing that would be a feature enhancement, not a bug fix.
I doubt whether it's worth the maintenance hassle.

My advice, for someone who wants that sort of feature, is to use a
C++-oriented skeleton instead of trying to limp along with yacc.c.
yacc.c was not designed to work with C++, it does not work well with
C++, and I suspect it will never work well with C++.

> - Also, there is an error in the comment of the block right above:
> #  if defined (__STDC__) || defined (__cplusplus)
> #   include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
> #   define YYSIZE_T size_t
> I think this comment is due to the compiler I formerly used,

No, it's because stdlib.h infringes on the C user's name space.  If
you give bison -y a Posix-conforming yacc grammar, Bison normally
attempts to impose no restrictions on user names, other than reserving
YY* and yy*.  Including <stdlib.h> violates that rule, because
stdlib.h defines names that begin with neither YY nor yy.

I doubt whether including <stdlib.h> is 100% innocuous in C++, but
that's not relevant here.  yacc.c is designed for C, not C++, and its
comments are aimed at C, not at C++.
(Continue reading)

Permalink | Reply | 0 comments |
headers
haberg | 9 Feb 14:24
Picon
Picon

(no subject)

. <20060208191638.A501551FAE <at> toucan.cs.ucla.edu> <87d5hx1hno.fsf_-_ <at> penguin.cs.ucla.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7E0F7DA4-A44C-4AC1-8F25-C3FFCB9BD86D <at> math.su.se>
Cc: Bison Bugs <bug-bison <at> gnu.org>,
 Akim Demaille <akim <at> lrde.epita.fr>
Content-Transfer-Encoding: 7bit
From: Hans Aberg <haberg <at> math.su.se>
Subject: Re: too many warnings from Bison CVS for Pike
Date: Thu, 9 Feb 2006 14:08:06 +0100
To: Paul Eggert <eggert <at> CS.UCLA.EDU>
X-Mailer: Apple Mail (2.746.2)

On 9 Feb 2006, at 01:48, Paul Eggert wrote:

>> I guess that if there is, as Akim says, a dedicated effort for the C-
>> parser to compile under C++ in current and upcoming Bison versions,
>
> That's not clear to me.  yacc.c happens to work, but I'd be surprised
> if the yacc.c code actually conforms to the current C++ standard, and
> thus there are no guarantees.  I don't recommend this usage, and I'd
> rather not document it.  People who misuse C++ compilers as if they
> were C compilers tend to know about the issues involved; but it's on
> them to get this to work, and it's their responsibility if it doesn't.

I just gave my impression from the input of Akim:

On 6 Feb 2006, at 09:59, Akim Demaille wrote:

>> If you want to support a compile C as C++ option,
(Continue reading)

Permalink | Reply | 0 comments |
headers
haberg | 9 Feb 19:45
Picon
Picon

(no subject)

. <20060208191638.A501551FAE <at> toucan.cs.ucla.edu> <87d5hx1hno.fsf_-_ <at> penguin.cs.ucla.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1BEBF0C4-DF01-4301-B884-7DE08DF920FA <at> math.su.se>
Cc: bug-bison <at> gnu.org
Content-Transfer-Encoding: 7bit
From: Hans Aberg <haberg <at> math.su.se>
Subject: Re: too many warnings from Bison CVS for Pike
Date: Thu, 9 Feb 2006 19:45:44 +0100
To: Paul Eggert <eggert <at> CS.UCLA.EDU>
X-Mailer: Apple Mail (2.746.2)

On 9 Feb 2006, at 01:48, Paul Eggert wrote:

> If a compiler defines __cplusplus, then yacc.c by default never calls
> memcpy, so there should never be a correctness issue about bypassing
> user-defined C++ assignment operators.  There is a way to override
> this, but it's not documented and nobody should use it unless they
> really know what they're doing, and (again) it's on them to get it to
> work.  For details, please see data/yacc.c; for an example, see
> src/parse-gram.c.

I can give three C++ possibilities:

Static C-parserstack. This seems what Bison is implementing for C++,  
i.e., yyoverflow is not defined, leaving up to the user to implement  
parser stack extensions. This will work with all C++ types, as long  
as the parser stack does not overflows.

Dynamic C-parserstack. This is what is Bison implements if
(Continue reading)

Permalink | Reply | 4 comments |
headers
haberg | 11 Feb 21:39
Picon
Picon

(no subject)

AE <at> toucan.cs.ucla.edu> <87r76axuvt.fsf_-_ <at> penguin.cs.ucla.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <085100B1-4168-4149-97E7-E2542993F35F <at> math.su.se>
Cc: bug-bison <at> gnu.org
Content-Transfer-Encoding: 7bit
From: Hans Aberg <haberg <at> math.su.se>
Subject: Re: too many warnings from Bison CVS for Pike
Date: Sat, 11 Feb 2006 16:20:16 +0100
To: Paul Eggert <eggert <at> CS.UCLA.EDU>
X-Mailer: Apple Mail (2.746.2)

On 11 Feb 2006, at 07:38, Paul Eggert wrote:

>> Dynamic C-parserstack. This is what is Bison implements if
>> __cplusplus is not defined. However, this should work under C++ as
>> well
>
> Implementing that would be a feature enhancement, not a bug fix.
> I doubt whether it's worth the maintenance hassle.

I think so, too. It needs someone dedicated to the task, if tried.

> My advice, for someone who wants that sort of feature, is to use a
> C++-oriented skeleton instead of trying to limp along with yacc.c.
> yacc.c was not designed to work with C++, it does not work well with
> C++,

So I think, as well. People use, I think, the C-skeletons, because  
the C++ ones in the past have lagged behind.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane