Resolving the bison.exe m4 Invalid argument Error when building MySQL/MariaDB/XtraDB on Windows

If you’ve tried compiling MySQL/MariaDB/XtraDB from source code on Windows, you may have run into the following error:

C:\GnuWin32\bin\bison.exe: m4: Invalid argument

Now, it is a known bug to receive this error if you install it to a location with spaces in the path. So don’t do that!

But, there are cases when you have not installed it to a path with spaces, and you still receive this error.

I’ve encountered it a number of times, and I’m not the only one (btw, thanks Venu for your existing work-around up to this point!).


Compile MySQL/MariaDB/XtraDB on Windows and receive the following error during compilation:

C:\GnuWin32\bin\bison.exe: m4: Invalid argument


As you can see, there is no space in the path that is even reported.

Let’s double-check that that is the path returned from the command line:

C:\mariadb-5.3\bld>where bison

C:\mariadb-5.3\bld>where m4

Again, both are stored in a location without spaces.

Let’s double-check what CMake reports for the bison path in CMakeCache.txt:

//path to the bison executable

Again, the same path with no spaces.

In the build output (either from Visual Studio or the Command Line), near the “bison.exe: m4: Invalid argument” error, you should see a link to the “build log” for that which failed, which contains additional information.

Opening that file, you’ll see this is the full command that is trying to be run:

C:\GnuWin32\bin\bison.exe -y -p MYSQL --output=C:/mariadb-5.3/bld/sql/ 
--defines=C:/mariadb-5.3/bld/sql/sql_yacc.h C:/mariadb-5.3/sql/sql_yacc.yy

I recommend trying to run it from the command line yourself.

If you’re already seeing the “bison.exe: m4: Invalid argument” error, then you’re likely going to see it here (which is good for later testing):

C:\mariadb-5.3\bld>C:\GnuWin32\bin\bison.exe -y -p MYSQL 
--defines=C:/mariadb-5.3/bld/sql/sql_yacc.h C:/mariadb-5.3/sql/sql_yacc.yy
C:\GnuWin32\bin\bison.exe: m4: Invalid argument

So what is going on?

Well, thanks to Wlad(!), he recommended I run Procmon to see what it reports.

  1. I downloaded and ran procmon.exe.
  2. Run bison command from command line:
    C:\GnuWin32\bin\bison.exe -y -p MYSQL 
    --defines=C:/mariadb-5.3/bld/sql/sql_yacc.h C:/mariadb-5.3/sql/sql_yacc.yy
  3. In procmon, search (ctrl + f) for “bison”
  4. Locate an entry (may see many) and look at the paths for the bison.exe executable (it is easy output to read).

The $Path for the bison entry said:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\GnuWin32\Bison

Aha! For one, that is just a directory with no executables. But for two, and more importantly, it has a “space” in the path.

So, that is the root cause of the problem.


Initially, I had run an installer to install GnuWin32 Bison. This added docs shortcuts to the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\GnuWin32\Bison location (and apparently created some registry entry that ultimately was used by VS2008), and links to those docs in my Start Menu.

Personally, I know where the docs are, so I can live without them being in my “Start Menu” (heck, maybe you could even copy them back, but it ultimately needs removed from the registry).

So, if you’re the same way, then this should work for you:

  1. Copy C:\GnuWin32 (and subdirs) to a safe location
  2. Run the bison uninstall (to remove the entry from the registry)
  3. Ensure current C:\GnuWin32 does not exist
  4. Ensure C:\ProgramData\Microsoft\Windows\Start Menu\Programs\GnuWin32 does not exist (those true docs will already be saved in the copy we made anyway, that will be restored to C:\GnuWin32)
  5. Re-boot computer (because stale registry values will remain and thus a restart is necessary – this I also detected with Procmon)
  6. Copy the saved GnuWin32 (and subdirs) back to C:\.
  7. Ensure C:\GnuWin32\bin is in the $PATH for Windows.

Now, re-run your command from the command line (or rebuild – but the command line command is much quicker for testing):

C:\mariadb-5.3\bld>C:\GnuWin32\bin\bison.exe -y -p MYSQL --output=C:/mariadb-5.3/bld/sql/ 
--defines=C:/mariadb-5.3/bld/sql/sql_yacc.h C:/mariadb-5.3/sql/sql_yacc.yy



Once that’s good to go, you’ll know your build will run successfully too (at least it won’t fail with this dreaded m4 error.)


Related Build Links:

Hope this helps.