I have experienced the same problem in linux (redhat 6.1) and netbsd, so you are not alone ;-) there is actually a file called dtimep.c-lexed, which is what it's *supposed* to lex to. it has been mentioned on this list that the lexing be taken out completely, which might not be a bad idea. shantonu On Fri, 28 Apr 2000, Steve Kelem wrote: > I'm trying to compile nmh-1.0.4 on Cygwin 1.0, NT4.0 SP6, and have > encountered the following problems. > 1. It doesn't recognize that I have "flex", and not "lex": > lex -nt ./dtimep.lex | sed -f ./lexedit.sed > dtimep.c > lex: not found > LEX FAILED: using pre-lexed dtimep.c > > 2. If I link "lex" to "flex", I get: > lex -nt ./dtimep.lex | sed -f ./lexedit.sed > dtimep.c > This produces a file containing the one line: > /* A lexical scanner generated by flex */ > > 3. If I get rid of the sed script, I get: > > flex -nt ./dtimep.lex > dtimep.c > ./dtimep.lex:44: `timezone' redeclared as different kind of symbol > /usr/i686-cygwin/include/time.h:81: previous declaration of `timezone' > ./dtimep.lex: In function `dparsetime': > ./dtimep.lex:176: `start_cond' undeclared (first use in this function) > ./dtimep.lex:176: (Each undeclared identifier is reported only once > ./dtimep.lex:176: for each function it appears in.) > ./dtimep.lex:246: warning: register variable `yy_cp' used in nested > function > ./dtimep.lex:254: warning: register variable `yy_bp' used in nested > function > ./dtimep.lex:256: warning: register variable `yy_current_state' used in > nested f > unction > ./dtimep.lex:278: warning: register variable `yy_act' used in nested > function > ./dtimep.lex:570: parse error before `static' > ./dtimep.lex:588: warning: return makes pointer from integer without a > cast > ./dtimep.lex:596: warning: return makes pointer from integer without a > cast > ./dtimep.lex:603: `number_to_move' undeclared (first use in this > function) > ./dtimep.lex:606: `dest' undeclared (first use in this function) > ./dtimep.lex:606: `source' undeclared (first use in this function) > ./dtimep.lex:673: `ret_val' undeclared (first use in this function) > ./dtimep.lex: In function `yylex': > ./dtimep.lex:428: parse error at end of input > dtime.c:241: warning: `yy_flex_alloc' used but never defined > dtime.c:243: warning: `yy_flex_free' used but never defined > dtime.c:271: warning: `yy_get_next_buffer' used but never defined > dtime.c:272: warning: `yy_fatal_error' used but never defined > > I guess this supports the comments in the Makefile that say that this > doesn't work with flex. > My question to this, is why doesn't it work with flex? What's all this > hacking with the sed script supposed to do? > Unfortunately, none of the rationale behind this decision of using lex > plus the sed script is documented, so it would take > some work to figure out what's going on and why. > > 4. There's some problem with the definition of timezone in the pre-lexed > version of dtimep.c. > make[2]: Entering directory `/usr/src/nmh-1.0.4/zotnet/tws' > gcc -c -DHAVE_CONFIG_H -I../.. -I. -I../.. -O2 dtimep.c > dtimep.c:17: `timezone' redeclared as different kind of symbol > /usr/i686-cygwin/include/time.h:81: previous declaration of `timezone' > make: *** [dtimep.o] Error 1 > > Fixing this with something like: > > diff -u -r1.1 zotnet/tws/dtimep.c > --- dtimep.c 2000/04/28 21:12:59 1.1 > +++ dtimep.c 2000/04/28 21:13:18 > @@ -12,7 +12,7 @@ > # include <sys/timeb.h> > #endif > > -#if !defined(HAVE_TM_GMTOFF) && defined(HAVE_TZSET) > +#if !(defined(HAVE_TM_GMTOFF) || ! defined(_TIME_H_)) && > defined(HAVE_TZSET) > extern int daylight; > extern long timezone; > extern char *tzname[]; > > results in: > % make > gcc -c -DHAVE_CONFIG_H -I../.. -I. -I../.. -O2 dtimep.c > ./dtimep.lex: In function `dparsetime': > ./dtimep.lex:189: invalid operands to binary / > make: *** [dtimep.o] Error 1 > > and here, it's not clear what the right answer is. > > Any ideas? > > Help! > > STeve > -- *-------------------------------------------* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *-------------------------------------------*
