I am getting this on a FreeBSD 5.4 system also. It seems that
make_parser.pl is not getting called to interpret the parse.y file.
If I run 'make_parser.pl byacc' manually, then the build completes.
It's been awhile since I've played with autoconf/automake.
The conflict appears to be somewhere in the following two entries:
I am getting this on a FreeBSD 5.4 system also. It seems that
make_parser.pl is not getting called to interpret the parse.y file.
If I run 'make_parser.pl byacc' manually, then the build completes.
I think the problem is that it seems we ship a parse.y with the tarball,
even though it should be generated. The shipped one seems to cause
problems on some systems. Can you try the following?
- Unpack the tarball again
- cd src
- rm parse.y
- cd ..
- ./configure etc
This works (without the patch). I forgot to mention that we had run
through that as well. I wasn't sure if the parse.y needed to be included
or not. Is there going to be a problem on systems that don't have
yacc installed? Or was it required anyway?
I believe we currently ship generated yacc output. I had forgotted about
that -- the patch I posted actually conflicts with that approach because
it removes files that could only be regenerated with yacc/bison.
I'm not sure what people prefer. Dropping the generated files from the
tarball is the cleanest solution, but we then require (f)lex/
yacc/bison. If we don't drop them, we could force invocation of
make_parser.pl by tweaking the Makefile rules.
*shrug*
Btw, make_parser.pl is only ever used in the parse.y case, but we also
have re-parse.y and rule-parse.y. Do the "@"-issues you're seeing not
occur with the latter two?
Btw, make_parser.pl is only ever used in the parse.y case, but we also
have re-parse.y and rule-parse.y. Do the "@"-issues you're seeing not
occur with the latter two?
parse.y is the only one of Bro's parsers that uses the @N construct.
I am getting this on a FreeBSD 5.4 system also. It seems that
make_parser.pl is not getting called to interpret the parse.y file.
If I run 'make_parser.pl byacc' manually, then the build completes.
Robin and I just stared at this for a while longer. What's happening is
that when the error occurs, the build re-generates parse.cc, even on the
initial build after unpacking the tarball. This is not what we intended.
It does not seem to be a flaw of the Makefile, but stem from the fact
that on some platforms, this rule...
... is triggered despite the fact that broparse.h, parse.cc, and parse.y
all have the same timestamp. Could you double-check that this is the
case on your tree, by unpacking the tarball and doing a
$ ls -la broparse.h parse.y parse.cc
-rw-r--r-- 1 kreibich networks 7396 Oct 5 13:36 broparse.h
-rw-r--r-- 1 kreibich networks 134265 Oct 5 13:36 parse.cc
-r--r--r-- 1 kreibich networks 24651 Oct 5 13:36 parse.y
?
What happens is that make determines that broparse.h/parse.cc need to be
rebuilt, but it uses the parse.y that's shipped with the tarball, and
not a new one generated from parse.in that'd have the yacc-hack applied
to it via make_parser.pl. So you end up with a broken parse.cc.
We'll think of a way to ensure that the parse.y is always compatible
with the local bison/yacc (if available).
I forgot to mention that we had run