Compilation errors

Gregory Stark wrote:

Does anyone happen to know what it is about my build environment that causes
these errors? I get a similar slew of errors from each flex lexer we built
including the plpgsql lexer, the ecpg lexer, etc. Do I have the wrong version
of flex installed? Something else? It's quite annoying, especially as the beta
version of Emacs I'm using seems to not be able to parse these lines.

In file included from gram.y:9493:
scan.c:7050: warning: no previous prototype for 'base_yyget_lineno'

[snip]

What versions of flex and bison are you using? It's a bit hard to
diagnose without knowing that ;-)

cheers

andrew

Am Mittwoch, 28. Februar 2007 16:23 schrieb Gregory Stark:

Does anyone happen to know what it is about my build environment that
causes these errors?

Nothing. Everybody gets them.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Am Mittwoch, 28. Februar 2007 16:23 schrieb Gregory Stark:

Does anyone happen to know what it is about my build environment that
causes these errors?

Nothing. Everybody gets them.

That's not what the buildfarm shows.

example:
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=sponge&dt=2007-02-28%20113002&stg=make

cheers

andrew

Peter Eisentraut <peter_e@gmx.net> writes:

Am Mittwoch, 28. Februar 2007 16:23 schrieb Gregory Stark:

Does anyone happen to know what it is about my build environment that
causes these errors?

Nothing. Everybody gets them.

I don't. What version of flex are you guys using?

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Peter Eisentraut <peter_e@gmx.net> writes:

Am Mittwoch, 28. Februar 2007 16:23 schrieb Gregory Stark:

Does anyone happen to know what it is about my build environment that
causes these errors?

Nothing. Everybody gets them.

I don't. What version of flex are you guys using?

flex 2.5.33

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Peter Eisentraut <peter_e@gmx.net> writes:

Am Mittwoch, 28. Februar 2007 16:23 schrieb Gregory Stark:

Does anyone happen to know what it is about my build environment that
causes these errors?

Nothing. Everybody gets them.

I don't. What version of flex are you guys using?

flex 2.5.33

Aha! Known to be broken, iirc. Use flex 2.5.4a

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Gregory Stark wrote:

flex 2.5.33

Aha! Known to be broken, iirc. Use flex 2.5.4a

No, the known breakages with flex were years ago; 2.5.33 has only been
out a year. I think 2.5.31 might have been the one we saw big problems
with (there's a note warning against using it on the flex sourceforge
page).

I think most of us do still use 2.5.4a, but it'd probably be a good idea
to check out 2.5.33 and see if it can be made to not generate warnings.
I'm certainly tired of seeing the warnings 2.5.4a creates ...

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Gregory Stark wrote:

flex 2.5.33

Aha! Known to be broken, iirc. Use flex 2.5.4a

No, the known breakages with flex were years ago; 2.5.33 has only been
out a year. I think 2.5.31 might have been the one we saw big problems
with (there's a note warning against using it on the flex sourceforge
page).

I think most of us do still use 2.5.4a, but it'd probably be a good idea
to check out 2.5.33 and see if it can be made to not generate warnings.
I'm certainly tired of seeing the warnings 2.5.4a creates ...

It gives me the same warnings that Greg reported.

I guess we could conditionally add prototypes for those functions to all
the .l files if you really want to move to 2.5.33. Kinda yucky, though.

cheers

andrew

I wrote:

I guess we could conditionally add prototypes for those functions to
all the .l files if you really want to move to 2.5.33. Kinda yucky,
though.

Actually, we couldn't.The definition section from the .l file gets
included after these functions. So we'd need to include something in
gram.y before including scan.c.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Actually, we couldn't.The definition section from the .l file gets
included after these functions. So we'd need to include something in
gram.y before including scan.c.

Actually, since we don't use any of those functions, the following
advice from the 2.5.33 flex manual seems useful:

A number of options are available for lint purists who want to
suppress the appearance of unneeded routines in the generated scanner.
Each of the following, if unset (e.g., `%option nounput'), results in
the corresponding routine not appearing in the generated scanner:

input, unput
yy_push_state, yy_pop_state, yy_top_state
yy_scan_buffer, yy_scan_bytes, yy_scan_string

yyget_extra, yyset_extra, yyget_leng, yyget_text,
yyget_lineno, yyset_lineno, yyget_in, yyset_in,
yyget_out, yyset_out, yyget_lval, yyset_lval,
yyget_lloc, yyset_lloc, yyget_debug, yyset_debug

(though `yy_push_state()' and friends won't appear anyway unless you
use `%option stack)'.

However, I'm not sure whether 2.5.4 will choke on unrecognized %option
commands --- if it has to be conditional on version it'll be a PITA.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Actually, we couldn't.The definition section from the .l file gets
included after these functions. So we'd need to include something in
gram.y before including scan.c.

Actually, since we don't use any of those functions, the following
advice from the 2.5.33 flex manual seems useful:

A number of options are available for lint purists who want to
suppress the appearance of unneeded routines in the generated scanner.
Each of the following, if unset (e.g., `%option nounput'), results in
the corresponding routine not appearing in the generated scanner:

input, unput
yy_push_state, yy_pop_state, yy_top_state
yy_scan_buffer, yy_scan_bytes, yy_scan_string

yyget_extra, yyset_extra, yyget_leng, yyget_text,
yyget_lineno, yyset_lineno, yyget_in, yyset_in,
yyget_out, yyset_out, yyget_lval, yyset_lval,
yyget_lloc, yyset_lloc, yyget_debug, yyset_debug

(though `yy_push_state()' and friends won't appear anyway unless you
use `%option stack)'.

However, I'm not sure whether 2.5.4 will choke on unrecognized %option
commands --- if it has to be conditional on version it'll be a PITA.

%option noyyget_in

causes flex 2.5.4a to barf:

/usr/bin/flex -CF -o'scan.c' scan.l
"scan.l", line 106: unrecognized %option: yyget
make[3]: *** [scan.c] Error 1

cheers

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

However, I'm not sure whether 2.5.4 will choke on unrecognized %option
commands --- if it has to be conditional on version it'll be a PITA.

%option noyyget_in
causes flex 2.5.4a to barf:

On closer investigation, flex does contain prototypes for these
functions, but it neglects to emit them! AFAICS this is simply a flex
bug, and one already reported. I added a comment here:
http://sourceforge.net/tracker/index.php?func=detail&amp;aid=1628314&amp;group_id=97492&amp;atid=618177

My advice is now that we do nothing, just wait for the flex folk to fix it.

regards, tom lane