Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#2373 closed defect (fixed)

mapparser.c does not compile in 5.0 branch

Reported by: warmerdam Owned by: sdlime
Priority: normal Milestone: 5.0.1 release
Component: Build Problems Version: unspecified
Severity: normal Keywords: parser
Cc: dmorissette

Description

Building MapServer from an svn checkout of the 5.0 branch on 64bit linux (gcc 3.4.5) I get:

mapparser.c:6: error: parse error before string constant
mapparser.c:6: warning: type defaults to `int' in declaration of `__IDSTRING'
mapparser.c:6: warning: data definition has no type or storage class
y.tab.c: In function `yyparse':
y.tab.c:397: warning: implicit declaration of function `yylex'
y.tab.c:436: warning: implicit declaration of function `yyerror'
make: *** [mapparser.o] Error 1

It appears that mapparser.c was regenerated after the 5.0 release with a different version of bison than usual (r6899).

I'm able to build ok by deleting mapparser.c/mapparser.h and regenerating but I think we need a maximally "safe" version in subversion.

Change History (19)

comment:1 Changed 13 years ago by tbonfort

also fails on regular x86

The current version was created by Steve on OSX. I posted about it a month ago on ms-dev, and Steve said to just regenerate it. Didn't commit it either as there seems to be some magic behind that file ;)

comment:2 Changed 13 years ago by sdlime

The bison generated files don't seem to be OS neutral. If we commit linux generated versions they likely won't work on OS X and will require the same delete/rebuild. However, there seem to be less issues with files generated on linux so perhaps that should be our reference OS?

Steve

comment:3 Changed 13 years ago by warmerdam

Steve,

Whatever the specific version of bison was that we were using in the past seemed to produce safe cross platform source code. I think we need to get back to generating the version for in subversion (and release tarballs) using that version. Do you still have access to the bison you were using previously?

comment:4 Changed 13 years ago by sdlime

I can't get to the cvs machine at the UMN anymore but I'm almost positive it was 1.875. I've not been using any of the 2.x releases.

Steve

comment:5 Changed 13 years ago by sdlime

It may be that my OS X version of bison is out-of-date but I could have sworn I'd updated it. -Steve

comment:6 Changed 13 years ago by warmerdam

Steve,

Looking at the revision it appears previously the parser was built with bison 1.35.

/* A Bison parser, made from mapparser.y 
   by GNU bison 1.35.  */ 

I suspect you are using to recent (or perhaps to mac specific) a version. If necessary, we could install bison 1.35 on download.osgeo.org and regenerate the parser there when needed.

comment:7 Changed 13 years ago by sdlime

But it's the current version is SVN that's causing the problems correct? So 1.35 should probably be avoided then. Let me check on my home machine and report back tonite.

Steve

comment:8 Changed 13 years ago by warmerdam

Steve,

The bit quoted was removed in r6899, so it suggests we were previously using bison 1.35.

comment:9 Changed 13 years ago by dmorissette

Cc: dmorissette added

comment:10 Changed 13 years ago by sdlime

Macs come with old versions of a lot of things, including bison- it's 1.35. Should I commit a parser generated by 1.875 and see if that helps? I wish I could get at the old CVS box to check for sure. I'll ping Tom.

Steve

comment:11 Changed 13 years ago by warmerdam

Steve,

OK, go ahead and try 1.875. We can test it on a few platforms fairly quickly.

comment:12 Changed 13 years ago by dmorissette

FYI r6061 from Steve says: "Added lexer/parser output from flex (v. 2.5.31) and bison (v. 1.35) to the repository." ... and looking at the source of that revision it is indeed 1.35.

So 1.35 should be fine. Perhaps it's the mac-specific version that's the issue?

Note that in r6373 I committed a version based on bison 2.3 (Linux) and a few weeks later Steve committed r6498 based on bison 1.35 and we heard no complaints in both cases. Steve, do you know what may have changed at your end between your r6498 and r6899 commits? Were both done from the same machine?

comment:13 in reply to:  11 Changed 13 years ago by sdlime

Replying to warmerdam:

Steve,

OK, go ahead and try 1.875. We can test it on a few platforms fairly quickly.

I committed late yesterday afternoon.

Steve

comment:14 in reply to:  12 Changed 13 years ago by sdlime

Replying to dmorissette:

FYI r6061 from Steve says: "Added lexer/parser output from flex (v. 2.5.31) and bison (v. 1.35) to the repository." ... and looking at the source of that revision it is indeed 1.35.

So 1.35 should be fine. Perhaps it's the mac-specific version that's the issue?

Note that in r6373 I committed a version based on bison 2.3 (Linux) and a few weeks later Steve committed r6498 based on bison 1.35 and we heard no complaints in both cases. Steve, do you know what may have changed at your end between your r6498 and r6899 commits? Were both done from the same machine?

I think that committing any "generated" files from mac os should probably be avoided. I gotta think that's the problem. I haven't had any problems on SuSE with the mac output but it seems problematic. My home machine is very stable so I don't know what could have changed between the revisions you mention. Same box, same bison version. However, the change at r6899 was actually a change to the parser code (mapparser.y) which is rare so perhaps that was the problem.

comment:15 Changed 13 years ago by warmerdam

I have tested the mapparser.c/h in trunk (r7023) on several platforms and it seems fine. Steve, could you commit a similarly generated mapparser.c/h in the 5.0 branch where the problem is?

comment:16 Changed 13 years ago by sdlime

Status: newassigned

Updated in 5.0 branch.

Steve

comment:17 Changed 13 years ago by warmerdam

Steve, this seems to address things for me. I think the bug report can be closed.

comment:18 Changed 13 years ago by sdlime

Resolution: fixed
Status: assignedclosed

comment:19 Changed 12 years ago by dmorissette

For the record, the 5.0 branch update was in r7028.

Note: See TracTickets for help on using tickets.