Compiling PHP on Windows 64 bit with VC9

Update 2009-10-28: added additional information for compiling on Windows 7.

This seems to one of the most difficult things for someone to explain. Hopefully this will shed some light on the subject of PHP Windows compilation and help you out.

There don’t seem to be any “Compile PHP on Windows x64″ guides, and even less than zero for the VC9 compiler (VC9 means Visual Studio 2008). I pieced together what I could from other guides I found (all were either woefully incomplete, confusing, and for either 32-bit or older VC versions) and created this guide. Hopefully it helps. My environment looks like this:

  • Windows Vista Home Premium 64-bit Windows 7 Professional 64-bit
  • Visual Studio 2008 Pro SP1

Let’s begin.

Preamble

A word of warning. This is a guide to compiling PHP for development. If you’re looking for a production-ready PHP binary for Windows 64-bit, you’re barking up the wrong tree, in many different ways.

  1. This is mostly a guide for those of us who develop on Windows with Apache. You shouldn’t be running Apache on Windows in production anyway, so if that’s what you’re looking for, you need to reevaluate your programming skills. PHP itself provides x64 VC9 binaries, but they’re not linked against Apache.
  2. I know almost nothing about C/C++. Compiling PHP requires no knowledge of C/C++. I only know enough to install what I need to make everything work.
  3. If you all you want is a PHP 5.2 binary for Windows 64-bit, go here and go wild. If you want to compile PHP on Windows 32-bit, go here; it’s a good guide (it’s what got me started). If you’re looking for a Windows 64-bit PHP 5.3 binary download, get it from me here.

If you’re looking to compile some futhermucking PHP on Windows 64-bit, read on.

Let’s get retarded

You need to download a bunch of crap. I hope you have a lot of disk space.

This will get you setup to compile PHP linked against Apache 2.2. This builds the CLI, CGI and apache2handler SAPIs (not ISAPI, if you want IIS, download it from PHP).

Let’s do it!

First (only if on Vista), download Daemon Tools Lite (or Virtual Clone Drive) and install it. You might have to reboot. Then download the Vista SDK update and right click on the Daemon Tools tray icon, and mount the SDK .iso. It should autoplay, so allow it and follow the installation instructions. This will take a while. If there’s a checkbox related to the installation of 64-bit stuff, make sure it’s checked. Like this:

Second, download Visual Studio 2008 and install it. Make sure to check 64-bit related stuff, like this:

vs2008setup

Go to your start menu, and you should see something similar to this:
vstools

That’s the x64 compiler command prompt. It’s a cmd shortcut that sets up all the environment variables needed to compile a C/C++ library for the x64 architecture. It’s important. Yes, my user icon is the stock cat picture. What?

Thirdly, if you don’t see something related to the Windows SDK in your start menu, download the .NET SDK and install that. Always check any 64-bit related stuff.

That was the hard part. Since it’s Windows (Windows Vista, even), I suggest you reboot. Let’s not upset her now. You’ve gotten this far only by her grace.

Now, download and install 7-zip. It’s a free, open-source archiving tool. Stop using stupid crap like WinRar. You aren’t downloading torrents in 1998 anymore. Then download the PHP build dependencies I created just for you and extract it to a clever place, like c:\php64. Then download and extract the PHP source code (you can get the bz2, since 7-zip can handle that) to c:\php64. Your directory structure should look like this:

- php64
-- php-5.x.x
-- deps

You are now ready to begin building stuff.

Compiling

Now it’s time to lift up your skirt and see if you got a pair.

First, a little explanation. The deps directory contains all the headers and libs that PHP needs to compile the different extensions (like curl for example). These came from PECL except for the apache libs, which came from blackbot. The stuff in the bin directory came from the binary tools provided by PHP here. As near as I can tell, the extensions need to be compiled with VC9. Apache was apparently compiled with VC8, which didn’t really seem to matter. I don’t know. The point is, all of these headers and libs work for what you are about to do, and that’s all that really matters. Right?

Here we go

Open up the x64 command prompt I alluded to earlier via the start menu, and cd to your php64 directory. The environment variables are all set up except for the binary tools (bison, zip and the like), so we need to modify the path. Do this:
path = %PATH%;c:\php64\deps\bin
echo %PATH%
That should modify your path and then spit it out. Mine looks like this:
path

Now we are ready to start the compilation process. I suggest you build the simplest possible version of PHP you can, and once you’ve gotten that to work, you can start enabling extensions. Or , if you’re man enough, you can skip right to the big finish and try compiling everything at once. I’ll walk you through the easier way.

cd into the php-5.x.x directory and type buildconf. This will (re)build the configuration file. Then run cscript /nologo configure.js --help This will show you a list of possible configuration switches.

The first build

We’re going to a very simple build that has most stuff disabled. Use this configure statement:
cscript /nologo configure.js --without-t1lib --without-xml --without-dom --without-simplexml --disable-xmlreader --disable-xmlwriter --without-iconv --disable-zlib --without-gd --disable-zip --disable-odbc --without-libxml

This won’t create a super useful PHP binary, but it’ll make sure that you have the ability to build PHP with no external dependencies. Type nmake to build. This will take about 5-10 minutes if there are no problems. If you’re watching it build, don’t be alarmed if it sits at parse_date.c for a minute or so: that’s normal. You’ll see a ridiculous amount of warnings, most of them about conversion issues. Disregard them.

When the build is done, cd to x64\Release_TS and type php -v to see your PHP version. Type php -m to see a list of all the modules we just compiled.
build1

Congratulations! You just compiled PHP on 64-bit Windows. You are among an elite group.

Extension Hell

Now, it’s time to make this PHP binary useful. It’s time to compile in some extensions.

Most of these extensions are built statically, which means they’re compiled into PHP and cannot be enabled/disabled; in effect they are always enabled. A few of them (gd, curl) are compiled as shared, which is what you’re probably used to, where you have a php_[extension name].dll line in your php.ini that you uncomment/comment with reckless abandon.

Let’s start easy, by enabling some more core extensions, like iconv and the xml stuff. cd back to the php-5.x.x directory and use this configure statement:
cscript /nologo configure.js --without-t1lib --without-gd --disable-zip --disable-odbc

When you run that, you should see a pretty list of enabled extensions. That list should now have xmlreader, xmlwriter, iconv, libxml, xml and dom in it.

If the configure statement failed, you probably don’t have your libs set up correctly. They should be in a directory called “deps” that is a sibling to php-5.x.x. If they are, and it still didn’t work, then add this to the configure statement: --with-php-build=c:\php64\deps. That will force the PHP build system to look for libs in that directory (by default it looks in ..\deps). You can troubleshoot configure errors by looking at the output. Most errors should be something like “Not found” for headers/libs.

Type nmake to build and wait for another 5-10 minutes. Verify that your extensions were built correctly by checking out the modules:
build2

If you’ve made it this far, you’re pretty much home free. All that’s left is enabling the apache2handler and the other extensions you want. The php64-deps.7z I made contains the headers and libs for the extensions that were easily available (i.e. the ones that PHP provided). If you need something more, like memcached for example, you’ll have to either build it yourself or scour the internet in the hopes that somebody already built it for Windows x64 (unlikely).

The Big Finish

Run this configure statement:
cscript /nologo configure.js --enable-apache2-2handler --with-curl --with-xsl --with-mcrypt --with-openssl --with-mysql --enable-sockets --enable-pdo --with-pdo-mysql --enable-soap --enable-mbstring --without-t1lib --with-pdo-odbc --with-bz2 --with-ldap --with-tidy --enable-exif --enable-mbregex --with-gettext --enable-shmop --enable-prefix=c:\lib\php --with-sqlite3 --with-xmlrpc --enable-zend-multibyte --with-mysqli

One note about the --enable-prefix switch: after building, you can run nmake install to install PHP to the directory you specify with this switch. Change the value to where you want PHP to be installed on your machine, or don’t run nmake install at all (it’s not required).

You’ll probably need to clean up the build output first. The easiest way to do this is to just delete everything in the x64\Release_TS directory. Now run nmake, wait another 5-10 minutes, and hope that everything worked.

Installation

A few of the extensions require some openssl binaries, namely ssleay32.dll and libeay32.dll. I’ve included these in the deps directory. You’ll need to copy them to wherever your php.exe binary is located. If you try to run PHP and Windows borks an error at you about PHP needing to close, then most likely it was looking for these dlls and didn’t find them. You’ll get that error if you try nmake install. It’s not serious, just copy those dlls and everything should be fine.

To enable curl and gd you’ll need to enable them in your php.ini… which means you need a php.ini. I’d just download one of the Windows zip packages from PHP and extract the php.ini-recommended or php.ini-development into your PHP binary’s directory. Make sure to change the extension_dir to the location of those dlls.

That’s it

And we’re done. Hopefully that all worked. Here are some common errors and how to troubleshoot them:

  • Unresolved externals: this means that the headers are referencing things that don’t exist. This means that you’re screwed, and you should try and find headers that don’t have this problem. Or, if you know C, you can try and fix it yourself.
  • Can’t find file: this means one of your source files (probably for an extension) is in the wrong place. You shouldn’t have this problem if you’re using my build dependencies archive. Regardless, this one’s an easy fix: just find the file and put it in the right place.

One last note, Fusion X-Lan has been providing pre-compiled Windows 64-bit binaries for a while, but it hasn’t been updated since PHP 5.2.5. The whole reason I wanted to compile PHP was so that I could run PHP 5.3 on my new 64-bit computer. Their binaries are much better than mine: they have all the extensions available, including the apache2 SAPI. Unfortunately, they’re old (almost two years now) and they also use the VC8 (or earlier) compiler. If you need PHP 5.2, use theirs. If you want to compile PHP 5.3 with VC9, use this guide, or just download the binary packages I provide.

I hope this was helpful. Leave a comment if you have any problems or find an issue with this guide.

October 17, 2009   Posted in: php, windows

6 Responses

  1. allenkoo - April 20, 2010

    thank you very much.very helpful.

  2. pavt - May 12, 2010

    first of all thanks for your guide. I thought of compiling php x64 following you guide, but then saw you have binaries readily available with openssl option (which is why I thought of compiling in the first place), so I thought I would just download your binaries and try them. So, I copied your binaries into my server setup and copied my current php.ini which has curl,openssl,msqli,sockets extensions enabled. But when I restart apache, it gives error saying “Cannot load C:/server/php/php5apache2_2.dll into server: The specified module could not be found.” I am using apache2.2.15 x64 version. The file is there, but it gives me the error. It would be nice if you could share you apache version too along with your php version.
    -thanks

  3. tmont - May 13, 2010

    @pavt – i’m not sure about the apache version, whatever the latest one was around last November (2.2.14 i think). i no longer use apache (i moved to nginx), but i was using 2.2.14 before i switched, and i was using these php binaries.

    that seems like a weird error for an apache version mismatch, though. your LoadModule directive should look like this (with the path changed appropriately):

    LoadModule php5_module "c:/lib/php/php5apache2_2.dll"

    i’m a little behind on my updates for this. in the next week or so i’m going to compile PHP 5.3.2 and release it linked against the latest apache binaries. maybe that will solve your problem.

  4. pavt - May 13, 2010

    thanks for your reply. I think that would solve the problem. My LoadModule is exactly the same even though mine is “c:/server/….”. The only other thing I can notice is your php libraries are compiled against msvcrt90.dll while my current php and apache libraries are compiled against msvcrt80.dll. Meanwhile I will also try to follow your guide and compile php just for fun.

  5. tmont - May 13, 2010

    @pavt – that would probably be the problem (although the error message is still pretty misleading). looks like your versions were compiled with vc8 (visual studio 2005). blackdot’s apache distributions are vc8, but i don’t have any problems with them. weird.

    anyway, you inspired me to update. i compiled PHP 5.3.2 linked against Apache 2.2.15 from blackdot. you can get it from me here: http://tommymontgomery.com/php64. phpinfo() output: http://tommymontgomery.com/php64/info

    hopefully this solves your problem. if you do decide to compile your own, let me know how it goes!

  6. pavt - May 20, 2010

    I dont know why, but I couldnt get apache running when I use your php binaries. I tried to disable all extensions, but even then apache fails (same happens when I use the binaries that I compile followng your procedure). I guess I just keep using the current version of php and use curl to connect to our sftp server.

    Anyways, thanks for taking your time in compiling new phpx64 binaries. I really hoped to use your phpx64 with static openssl version on our server.

Leave a Reply