Do a grep of your source files to locate which file eBEGINi is located in. It does not appear in any of the files included in you e-mail.
----- Original Message ----- From: Mark Hounschell <ma...@compro.net> To: help-bison@gnu.org; flex-h...@lists.sourceforge.net Cc: Sent: Friday, November 1, 2013 6:36 AM Subject: [Flex-help] lex/yacc/gcc help I am trying to port some code from an old unix box to Linux. It is a microcode compiler for an old CPU board. This code uses lex/yacc/cc. Obviously all works on this old unix box. I am completely lex/yacc ignorant but am not gcc ignorant. I am hoping someone can give me some advise as to what I need to do. I've subscribed and sent this email to both the flex-help and the help-bison mailing lists because I really have no idea what the problem really is. I hope that is appropiate. The Linux distribution OS is OpenSuSE-12.3 and the software versions in use are: gcc-4.7-7.1.1.i586 glibc-2.17-4.7.1.i586 flex-2.5.37-2.1.1.i586 bison-2.6.5-2.1.1.i586 The actual error I get from gcc when compiling this stuff on Linux is: # make ./translate5 cpu.def cat yacc1.yinit yacctoks yacc2.yinit yaccrules yacc3.yinit > yacc.in yacc -d yacc.in cat lex1.linit lextext lexfield lex2.linit > lex.in flex -l lex.in gcc -ansi -w y.tab.c -o cpu.asm -lgcc yacc.in: In function ëyyparseí: yacc.in:2322:3: error: unknown type name ëBEGINí make: *** [cpu.asm] Error 1 This is the output from the legacy "unix" machine: # make translate5 cpu.def cat yacc1.yinit yacctoks yacc2.yinit yaccrules yacc3.yinit > yacc.in /usr/bin/yacc -d yacc.in cat lex1.linit lextext lexfield lex2.linit > lex.in /usr/bin/lex lex.in 2277/3600 nodes(%e), 10911/17500 positions(%p), 1561/1900 (%n), 89797 transitions , 136/170 packed char classes(%k), 3614/5000 packed transitions(%a), 2433/4000 output slots(%o) /bin/cc -z -B/lib/ -t0 y.tab.c -ly -ll -v -w -o cpu.asm /lib/cpp y.tab.c /tmp/ctm030464 -DON_SEL -Dselport -DGOULD_PN -DCOFF /lib/ccom /tmp/ctm030464 /tmp/ctm030463 -Xll -w /bin/as -o y.tab.o /tmp/ctm030463 /bin/ld -X /lib/crt0.o -e start -o cpu.asm -z y.tab.o -ly -ll -lc Now from my limited mis/understanding the ëBEGINí in the compile failure above seems to be a "lex thing"? Yet it seems to appear in a yacc file? If I look at what ends up being in the y.tab.c file on both machines I see: Legacy unix box: case 207: # line 2305 "yacc.in" { if (yychar != -1) { yyclearin; while (yyleng > 0) { unput(yytext[--yyleng]); }} BEGIN ctxn;} break; } goto yystack; /* stack new state and value */ } The Linux box: case 208: /* Line 1778 of yacc.c */ #line 2318 "yacc.in" { if (yychar != -1) { yyclearin; while (yyleng > 0) { unput(yytext[--yyleng]); }} BEGIN ctxn;} break; Both the above come from the yacc3.yinit file. cnum : /*empty*/ { if (yychar != -1) { yyclearin; while (yyleng > 0) { unput(yytext[--yyleng]); }} BEGIN ctxn;} ; The only references to "ctxn" I find are from a lex1.linit and lex2.linit files. lex1.linit: %C %e 3600 %p 17500 %a 5000 %o 4000 %n 1900 %k 170 int statnum=0; int externum=0; int passc=0; int linec=1; int errc=0; int eolflag = 0; int codeflag = 0; int lque = 0; int plinec = 0; int spacec = 1; int pagesize = 55; int skippage = 0; int skipline = 0; int pagecnt = 1; int type1, type2, type3, type4, type5, type6, type7, type8; int type9, typeA, typeB, typeC, typeD, typeE, typeF; %S ex co pb lc rz bd al eq va code %S rz2 bd2 sp hd hd2 hd3 hd4 dir ctxn . . . . lex2.linit: <code,ctxn>("#"[0-9a-fA-F]+|[0-9]+) { if (yytext[0] == '#') { yylval.nvaltype.nval=htoi(yytext); if (yyleng > 9) fprintf(stderr, "Literal value '%s' out of range at line %d\n", yytext, linec); } else yylval.nvaltype.nval=atoi(yytext); yylval.nvaltype.ntype=2; BEGIN code; return(NUM); } <code>[ \t] {} ^[ \t]+ {BEGIN code;} <ctxn,code>[A-Za-z][\$\.A-Za-z0-9]* {BEGIN code; return(p_symbol(yytext));} <code>\n {p_eol(); ++linec;} [ ,\t] {} \n {p_eol(); ++linec;BEGIN 0;} . {return(YYERRCODE);} %% #include "process.c" Again, I am completely ignorant of lex and yac. Very strange and cryptic looking code. I would greatly appreciate any pointers from anyone. Thanks in advance Regards Mark ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Flex-help mailing list flex-h...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flex-help _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison