parser.yy:87: error: ISO C++ forbids declaration of 'rule_info' with no type
Ryan Schmidt
bison -v -o ./parser.cc parser.yy
/usr/bin/g++-4.0 -O2 -I/mp/include `llvm-config --cppflags` -I. -I. -
DPURELIB='"/mp/lib/pure-0.13"' -c -o pure.o pure.cc
parser.yy:87: error: ISO C++ forbids declaration of 'rule_info' with
no type
parser.yy:87: error: expected ';' before '*' token
parser.yy:88: error: ISO C++ forbids declaration of 'pat_rule_info'
with no type
parser.yy:88: error: expected ';' before '*' token
parser.yy:90: error: ISO C++ forbids declaration of
'comp_clause_list' with no type
parser.yy:90: error: expected ';' before '*' token
parser.yy:91: error: ISO C++ forbids declaration of 'comp_clause'
with no type
parser.yy:91: error: expected ';' before '*' token
parser.yy:93: error: ISO C++ forbids declaration of 'sym_info' with
no type
parser.yy:93: error: expected ';' before '*' token
make: *** [pure.o] Error 1
Perhaps the problem is that bison in MacPorts was just updated to
2.4. Maybe it is less permissive than bison 2.3 was?
Albert Graef
> I have this error building the latest trunk, r408, on Mac OS X 10.4.11:
>
> bison -v -o ./parser.cc parser.yy
> /usr/bin/g++-4.0 -O2 -I/mp/include `llvm-config --cppflags` -I. -I. -
> DPURELIB='"/mp/lib/pure-0.13"' -c -o pure.o pure.cc
> parser.yy:87: error: ISO C++ forbids declaration of 'rule_info' with
> no type
>
> Perhaps the problem is that bison in MacPorts was just updated to
> 2.4. Maybe it is less permissive than bison 2.3 was?
Could also be a quirk with the gcc version that you use. Could you
please send me the generated parser.hh file, please?
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Ryan Schmidt
> Ryan Schmidt wrote:
>
>> I have this error building the latest trunk, r408, on Mac OS X
>> 10.4.11:
>>
>> bison -v -o ./parser.cc parser.yy
>> /usr/bin/g++-4.0 -O2 -I/mp/include `llvm-config --cppflags` -I. -I. -
>> DPURELIB='"/mp/lib/pure-0.13"' -c -o pure.o pure.cc
>> parser.yy:87: error: ISO C++ forbids declaration of 'rule_info' with
>> no type
>> [...]
>>
>> Perhaps the problem is that bison in MacPorts was just updated to
>> 2.4. Maybe it is less permissive than bison 2.3 was?
>
> Could also be a quirk with the gcc version that you use. Could you
> please send me the generated parser.hh file, please?
My gcc version hasn't changed; it's still Apple's gcc 4.0.1 from
Xcode 2.5.
Here's the parser.hh file generated by bison 2.4.
Albert Graef
> My gcc version hasn't changed; it's still Apple's gcc 4.0.1 from
> Xcode 2.5.
>
> Here's the parser.hh file generated by bison 2.4.
Yes, I see, the problem is with bison 2.4 which handles prologue code
(%{...%}) in a new (and incompatible) way. Consequently, the parser.hh
file doesn't contain the necessary C++ declarations from parser.yy any more.
Adding insult to injury, AFAICT there's *no* way to fix that in a way
which is compatible with earlier bison releases. A really really bad
decision by the bison team IMHO, I'd expect that to break most bison
sources which aren't just toy parsers.
Details are available here (see item "Handling of traditional Yacc
prologue blocks is now more consistent but potentially incompatible with
previous releases of Bison."):
http://groups.google.com/group/comp.compilers/browse_thread/thread/5444af23c856c2cb
Ryan, I could fix this so that it works with bison 2.4 (and nothing
else), but given that bison 2.4 is fairly new, I think that we should
stick with bison 2.3 for now. Is that a problem with your build environment?
Ryan Schmidt
> Ryan Schmidt wrote:
>
>> My gcc version hasn't changed; it's still Apple's gcc 4.0.1 from
>> Xcode 2.5.
>>
>> Here's the parser.hh file generated by bison 2.4.
>
> Yes, I see, the problem is with bison 2.4 which handles prologue code
> (%{...%}) in a new (and incompatible) way. Consequently, the parser.hh
> file doesn't contain the necessary C++ declarations from parser.yy
> any more.
>
> Adding insult to injury, AFAICT there's *no* way to fix that in a way
> which is compatible with earlier bison releases. A really really bad
> decision by the bison team IMHO, I'd expect that to break most bison
> sources which aren't just toy parsers.
>
> Details are available here (see item "Handling of traditional Yacc
> prologue blocks is now more consistent but potentially incompatible
> with
> previous releases of Bison."):
> http://groups.google.com/group/comp.compilers/browse_thread/thread/
> 5444af23c856c2cb
>
> Ryan, I could fix this so that it works with bison 2.4 (and nothing
> else), but given that bison 2.4 is fairly new, I think that we should
> stick with bison 2.3 for now. Is that a problem with your build
> environment?
We would have to create a new bison23 port to bring back the 2.3
version. I already have one other MacPorts user complaining about
bison 2.4, so we may have to do this anyway for now. So if you can't
make pure work with both bison 2.3 and 2.4, then I won't ask you to
force everyone up to 2.4 right now and we'll deal with it on our end.
Albert Graef
> We would have to create a new bison23 port to bring back the 2.3
> version. I already have one other MacPorts user complaining about
> bison 2.4, so we may have to do this anyway for now. So if you can't
> make pure work with both bison 2.3 and 2.4,
I see no way to do this without resorting to horrible autoconf hackery,
sorry. :(
> then I won't ask you to force everyone up to 2.4 right now and we'll deal with it on our end.
That would be much preferred, thanks.
John Cowan
> Ryan, I could fix this so that it works with bison 2.4 (and nothing
> else), but given that bison 2.4 is fairly new, I think that we should
> stick with bison 2.3 for now. Is that a problem with your build environment?
How about allowing byacc instead?
--
A few times, I did some exuberant stomping about, John Cowan
like a hippo auditioning for Riverdance, though co...@ccil.org
I stopped when I thought I heard something at http://ccil.org/~cowan
the far side of the room falling over in rhythm
with my feet. --Joseph Zitt
Albert Graef
> How about allowing byacc instead?
Well, the current parser uses a few bison-specific features. It would be
doable, but extra work, and there's much more important stuff on my TODO
list.