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 in case if you change the parser code (sql_yacc.yy) or if you are working directly from development branch (bzr launchpad), then the build breaks to generate the yacc files (sql_yacc.h and sql_yacc.cc) with an error bison: M4: Invalid argument as shown below:
1>------ Build started: Project: sql, Configuration: Debug Win32 ------ 1>Generating sql_yacc.h, sql_yacc.cc 2>------ Build started: Project: GenServerSource, Configuration: Debug Win32 ------ 2>Generating sql_yacc.h, sql_yacc.cc 1>bison: m4: Invalid argument 1>Project : error PRJ0019: A tool returned an error code from "Generating sql_yacc.h, sql_yacc.cc" 1>sql - 1 error(s), 0 warning(s) 2>bison: m4: Invalid argument 2>Project : error PRJ0019: A tool returned an error code from "Generating sql_yacc.h, sql_yacc.cc" 2>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.
But, again if you wanted to change the code or happen to save sql_yacc.yy, then it starts generating the files and build will break. It looks like lot of people are experincing 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 directy 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 weired, but atleast there is a work around to change the parser code on Windows now; and it works great including Visual studio also starts building without any errors. But if you remove m4.exe from sql directory, then things starts to break immediately.
Related posts:
3 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