gcc: expected »=«, »,«, »;«, »asm« or »__attribute__« before »YY_PROTO«

[harvey]

Habe gerade versucht tinycobol-0.63 zu kompilieren (unter Suse Linux 10.2) und erhalte beim Aufruf von make folgende Fehlermeldung:


Making all in compiler
make[1]: Entering directory `/home/harald/Documents/cobol/tinycobol-0.63/compiler'
gcc -I/usr/include -I/usr/local/include -I../lib -I../ -c scan.c
scan.c:1073: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »YY_PROTO«
scan.l:744: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »YY_PROTO«
make[1]: *** [scan.o] Fehler 1
make[1]: Leaving directory `/home/harald/Documents/cobol/tinycobol-0.63/compiler'



Was bedeutet das und kann man das evtl. leicht beheben?

[Boron]

Zeig uns doch mal die Zeilen 1073 der Datei scan.c wie in der Fehlermeldung steht.

[harvey]

Zeig uns doch mal die Zeilen 1073 der Datei scan.c wie in der Fehlermeldung steht.

Voila:

1071 /** The main scanner function which does all the work.
1072 */
1073 YY_DECL
1074 {
1075 register yy_state_type yy_current_state;
1076 register char *yy_cp, *yy_bp;
1077 register int yy_act;
1078
1079 #line 116 "scan.l"
1080

[panzi]

Zeig lieber die Zeile 116 aus scan.l denn scan.c ist eine generierte Datei. Das ist (f)lex code. Also code des lexers. Kann auch sein das due nicht ide richtige version von (f)lex installiert hast. Oder eventuell lex statt flex oder umgekehrt und es wird genau das andere gebraucht. Ist alles sehr messy.
Offensichtlich gibts einen Syntaxfehler im Makro YY_DECL. Müsstest zeigen wie das deklariert ist. Aber ich denk ja, dass das irgendein komischer Folgefehler ist. Der Fehler liegt entweder in der scan.l Datei oder ganz wo anders (in der Konfiguration oder so). Oft bewirken Syntaxfehler im lex Code nicht das lex schreit sondern das lex kaputten C Code generiert. (das selbe ist auch bei yacc/bison und der Datei parser.y; evenuell ist das dort sogar noch häufiger der Fall) Das ist dann besonders beschissen rauszufinden.

[harvey]

Zeig lieber die Zeile 116 aus scan.l

Sorry, dass es ein bisschen länger gedauert hat, aber irgendwie funktionierte das hier mit der Benachrichtigung nicht so ganz...

Voila, der Code:


116 %%
117 %{
118 extern int curr_division;
119 extern int need_subscripts;
120 /* struct copy_symbols *tmp = NULL; */
121
122 switch (curr_division) {
123 case CDIV_IDENT:
124 scdebug("-> IDENT_ST\n");
125 BEGIN IDENT_ST;
126 break;
127 case CDIV_ENVIR:
128 scdebug("-> ENVIR_ST\n");
129 BEGIN ENVIR_ST;
130 break;
131 case CDIV_DATA:
132 scdebug("-> DATA_ST\n");
133 BEGIN DATA_ST;
134 break;
135 case CDIV_PROC:136 /* stabs_started=1; */
137 scdebug("-> INITIAL\n");
138 BEGIN INITIAL;
139 break;
140 case CDIV_COMMENT:
141 scdebug("-> COMMENT_ST\n");
142 BEGIN COMMENT_ST;
143 break;
144 case CDIV_COMMENT1:
145 scdebug("-> COMMENT1_ST\n");
146 BEGIN COMMENT1_ST;
147 break;
148 case CDIV_FD:
149 scdebug("-> FD_ST\n");
150 BEGIN FD_ST;
151 break;
152 case CDIV_REDEF:
153 scdebug("-> REDEF_ST\n");
154 BEGIN REDEF_ST;
155 break;
156 case CDIV_SUBSCRIPTS:
157 scdebug("-> SUBSCRIPTS_ST\n");
158 BEGIN SUBSCRIPTS_ST;
159 break;
160 case CDIV_EXCEPTION:
161 scdebug("-> EXCEPTION_ST\n");
162 BEGIN EXCEPTION_ST;
163 break;
164 case CDIV_PIC:
165 scdebug("-> PIC_ST\n");
166 BEGIN PIC_ST;
167 break;
168 case CINITIAL:
169 scdebug("-> INITIAL\n");
170 BEGIN INITIAL;
171 break;
172 }
173 curr_division=0; /* avoid new state switch */
174 %}

[panzi]

puh. nein, ich denk da kann ich dir net helfen. da müsste man sich besser mit dem source auskennen um das zu finden.