Thread: Compilation errors
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' scan.c:7059: warning: no previous prototype for 'base_yyget_in' scan.c:7067: warning: no previous prototype for 'base_yyget_out' scan.c:7075: warning: no previous prototype for 'base_yyget_leng' scan.c:7084: warning: no previous prototype for 'base_yyget_text' scan.c:7093: warning: no previous prototype for 'base_yyset_lineno' scan.c:7105: warning: no previous prototype for 'base_yyset_in' scan.c:7110: warning: no previous prototype for 'base_yyset_out' scan.c:7115: warning: no previous prototype for 'base_yyget_debug' scan.c:7120: warning: no previous prototype for 'base_yyset_debug' scan.c:7154: warning: no previous prototype for 'base_yylex_destroy' -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
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&aid=1628314&group_id=97492&atid=618177 My advice is now that we do nothing, just wait for the flex folk to fix it. regards, tom lane