Strange Bro build problem with yacc/bison

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:

broparse.h parse.cc: parse.y
        $(YACC) $(YFLAGS) parse.y
        @sed '/extern char.*getenv/d;s/yylex/brolex/' <y.tab.c >parse.cc
        @mv y.tab.h broparse.h
        @rm y.tab.c

parse.y: parse.in make_parser.pl
        @rm -f parse.y
        perl -w $(srcdir)/make_parser.pl "$(YACC)"
        chmod -w parse.y

Thanks,

Randy

Yeah, we ran into this on a FreeBSD 6.1 machine too. It wasn't clear
at the time whether it was a general 6.1 problem or unique to our

build;

Hi Randy,

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

and see if it works?

Cheers,
Christian.

This works (without the patch). :slight_smile: 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?

Thanks,

Randy

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?

Cheers,
Christian.

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.

    Vern

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...

broparse.h parse.cc: parse.y
        $(YACC) $(YFLAGS) parse.y
        @sed '/extern char.*getenv/d;s/yylex/brolex/' <y.tab.c >parse.cc
        @mv y.tab.h broparse.h
        @rm y.tab.c

... 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).

Cheers,
Christian.

Christian,

All had the same timestamp.

I did an experiment and gave parse.y an older timestamp than the other
files. In that case, gmake ran without any errors.

Randy