Changing MySQL parser code on Windows – Build breaks due to Bison
In case if you working on Windows environment for MySQL development (sometimes I use visual studio for easy debugging); and if you change the parser code (sql_yacc.yy) or if you working directly from the development branch (bzr launchpad), then the build breaks to generate the parser yacc files (sql_yacc.h and sql_yacc.cc) with an error bison: M4: Invalid argument as shown below:
------ Build started: Project: sql, Configuration: Debug Win32 ------ Generating sql_yacc.h, sql_yacc.cc ------ Build started: Project: GenServerSource, Configuration: Debug Win32 ------ Generating sql_yacc.h, sql_yacc.cc bison: m4: Invalid argument Project : error PRJ0019: A tool returned an error code from "Generating sql_yacc.h, sql_yacc.cc" sql - 1 error(s), 0 warning(s) bison: m4: Invalid argument Project : error PRJ0019: A tool returned an error code from "Generating sql_yacc.h, sql_yacc.cc" GenServerSource - 1 error(s), 0 warning(s) |
But if use source zip file for any particular release, then it won’t fail as the files (sql_yacc.cc and sql_yacc.h) are pre-built and copied to the distribution zip file.
It looks like lot of people are experiencing the same problem to build parser code on Windows using any recent version of bison (not just MySQL code base).
Both bison.exe and m4.exe are in the path and they are the latest version; but still it fails..
c:\mysql-5.1\sql>which bison C:\Gnu\GetGnuWin32\gnuwin32\bin\bison.EXE c:\mysql-5.1\sql>which m4 C:\Gnu\GetGnuWin32\gnuwin32\bin\m4.EXE c:\mysql-5.1\sql>bison --version bison (GNU Bison) 2.4.1 c:\mysql-5.1\sql>m4 --version m4 (GNU M4) 1.4.13 |
It looks like the problem is with Windows version of bison to pick m4 executable even though m4 is in the path. For example, you can directly try to generate the files from sql directory using bison as…
c:\mysql-5.1\sql>bison -y -p MYSQL --defines=sql_yacc.h --output=sql_yacc.cc sql_yacc.yy bison: m4: Invalid argument |
The work around what I found is to copy m4.exe to sql directory directly, so that bison can pick from local working directory, then everything starts working as expected.
c:\mysql-5.1\sql>bison -y -p MYSQL --defines=sql_yacc.h --output=sql_yacc.cc sql_yacc.yy bison: m4: Invalid argument c:\mysql-5.1\sql>ls -al sql_yacc.* -rw-rw-rw- 1 venu 0 413012 2010-02-07 11:58 sql_yacc.yy c:\mysql-5.1\sql>which m4 C:\Gnu\GetGnuWin32\gnuwin32\bin\m4.EXE c:\mysql-5.1\sql>copy C:\Gnu\GetGnuWin32\gnuwin32\bin\m4.EXE . 1 file(s) copied. c:\mysql-5.1\sql>which m4 c:\mysql-5.1\sql\m4.EXE c:\mysql-5.1\sql>bison -y -p MYSQL --defines=sql_yacc.h --output=sql_yacc.cc sql_yacc.yy c:\mysql-5.1\sql>ls -al sql_yacc.* -rw-rw-rw- 1 venu 0 1510389 2010-02-07 14:33 sql_yacc.cc -rw-rw-rw- 1 venu 0 30532 2010-02-07 14:33 sql_yacc.h -rw-rw-rw- 1 venu 0 413012 2010-02-07 11:58 sql_yacc.yy |
Kind of weird, but at least there is a work around to change the parser code on Windows now; apart from command-line, even visual studio starts working without any errors. But if you remove m4.exe from sql directory, then things starts to break immediately.
Related posts:
6 Comments
Thanks Venu; since an year+ and to build and extend our storage engine, we used to build yacc on Linux and copy the files to Windows; it’s a painful process
I just tried this on Windows 7 and it works
Comment :: February 7, 2010 @ 3:02 pm
I’ve seen that with bison installed into default path (with spaces C:\Program Files\…). The bug was apparent in bison 2.4. I filed a bug some half year ago, still no reply). Also QT folks document it here http://trac.webkit.org/wiki/BuildingQtOnWindows. Meanwhile you might want to check which m4.exe bison is looking for, using procmon.
Comment :: February 7, 2010 @ 4:22 pm
just for completeness, having bison.exe and m4.exe in C:\Gnuwin32\bin (and nowhere else in PATH) works for me.
Comment :: February 7, 2010 @ 4:27 pm
Installing Bison’s PATH entry as C:\Progra~1\GnuWin32\bin seems to work for me and removes the need to copy m4.exe locally. Installing bison to c:\gnuwin32 should also work. The problem as wlad noted is the space in the path to m4.exe. Oh, and I also had to hunt down an older version of Bison that I’d installed elsewhere and didn’t support the –defines parameter. Running which m4.exe in a cmd prompt to check you are getting what you expect is a good idea.
Comment :: March 29, 2010 @ 4:00 am
I had to put m4.exe in the same directory as my .y grammar to get bison to work. It wasn’t working in the bin directory with Bison. Don’t know why.
Comment :: June 28, 2011 @ 11:26 am
Thanks Venu! This has been a very helpful work-around.
However, I did recently get to the bottom of this, at least on my system. So if you’ve installed it to a location with “no” spaces, and still encounter this error, then this is likely to help:
http://www.chriscalender.com/?p=798
(It’s a bit lengthy, so I’ve just posted the url.)
Comment :: February 2, 2012 @ 8:29 am