Saturday 13 June 2015

PHP: getting PHP7 alpha running on Windows 8.1

G'day:
I'm mostly writing this in case anyone else has the issues I had with this. Getting PHP 7 alpha (released yesterday: "PHP 7.0.0 Alpha 1 Released") was not as straight forward as getting the dev releases of PHP 7 working. Especially for someone like me who's not really that au fait with PHP.

You might remember I got one of the dev releases of PHP 7 running the other week: "Getting PHP 5.x & 7-dev running on Windows/Apache". That was a bit of horsing about, but mostly because I was getting both versions working at once. Getting PHP 7 working stand-alone was a piece of piss: download, unzip, run (from the command line); or with the additional step of using the PHP7 Apache module instead of the PHP 5 one.

So I presumed getting the PHP 7 alpha running would be a matter of downloading, and replacing the files in my PHP/7 dir with the new one. No.

I will start by saying this seemed like a right pain in the arse to sort out, but on reflection my entire efforts to get it working were spread over 30min in the bar @ LHR/T2 last night where the focus was mostly on the pint in front of me (lovely lovely Wild River from Fullers), and about another hour of swearing this afternoon, perched on my bed in the B&B I'm in. Now I've migrated to the pub, and I had it cracked within about 300ml of my first pint.

So if I take nothing else away from this: IT issues are best solved in the pub with a Guinness.

Right, so first things first: I'm running Windows 8.1, 64-bit, and I'm running Apache 2.4.10. I mostly run my PHP stuff via a browser as most of my work is web-related, and given my CFML background, I'm just used to working through a browser. I say this because it's significant in my troubleshooting.

I downloaded the PHP 7  alpha (I'm trying for keyword relevance here, so sorry for the repetition of "PHP 7") from the official drop site: http://windows.php.net/qa/. I grabbed the x64 thread-safe version (I really don't get the whole "thread-safe" vs "non-thread-safe" version thing. I can't see why one would want a non thread-safe version? But anyway), The file is php-7.0.0alpha1-Win32-VC14-x64.zip.

What I'd normally do with a new PHP drop is simply set up a new directory for it, stick the files in it, do a diff on the new version's php.ini-development and my own php.ini from my current working version, and create a new php.ini based on the two. Then I rename the existing dir to - in this case -
C:\apps\php\7.old, and stick the new one in as C:\apps\php\7. Apache's already expecting PHP 7 to be in that directory, so generally I expect to simply crank up Apache and I'm away.

Nope. Instead, I got Apache failing to start (I'm running it as a Windows service), and the event log says this:

Syntax error on line 531 of C:/apps/apache/httpd/conf/httpd.conf: Cannot load C:/apps/php/7/php7apache2_4.dll into server: The specified module could not be found.
Hmmm. 531 is the first line of this bit:

LoadModule php7_module "C:/apps/php/7/php7apache2_4.dll"
AddHandler application/x-httpd-php .php
PHPIniDir "C:/apps/php/7/"

I checked C:\apps\php\7\ and... well... no. The file wasn't there. This is actually a fairly familiar problem to me. I've had a couple of occasions of them forgetting to put the Apache module in the zip file. I dunno how they manage to miss it. Surely part of the build process is at least to start an Apache service? Apparently not.

OK, so I don't have php7apache2_4.dll. Except I do... I copy the one over from the 7.old dir. I figured that given this is only the difference between a dev build from a coupla weeks ago and the alpha released yesterday, this file probably hasn't changed. I dropped the old one in and restarted Apache and... same error. F*** it.

Google.

I googled "php 7 missing php7apache2_4.dll" (or something like that), and found a link to this: " Bug #69801: missing php7apache2_4.dll", which stated:

Confirmed and thanks for the ping, will be fixed at least in the alpha2. In the meanwhile you can use these builds http://windows.php.net/downloads/snaps/ostc/69801/
And indeed in that directory was the x64 version of the file I needed. I grabbed it, chucked it into my php/7/ dir, and restarted. Same error.

At which point in time it was time for my flight, so I gave up for the evening. Now this afternoon I resumed trying to work out "WTF". Well I stuck a Twitter message up in case anyone had a quick fix:

No replies to that so far.

I googled some more this afternoon, and spotted that same bug ticket. It'd been updated to observe they'd re-packaged the release, so I grabbed that (in case anything else had changed, or they needed to recompile the DLL or anything), and tried that. No: still bung.

More googling yielded really not much. Oh, I found an alternative build at the Apache Lounge, tried that, same thing.

Oh, I also switched back to my old dev build of PHP 7, and that still worked fine. So I was confident that Apache and everything else was OK. It was an issue with this alpha. I reached out (read: "complained") on Twitter again, and got some traction this time:

Bardnet / flattenmapper gave me a motivation boost, and my thirst was building so I headed over here to the pub (I'm now on my second Guinness, btw). He'd linked me through to Dependency Walker, and I've downloaded that.

However I had an epiphany in the interim, Well not an epiphany per se, but I decided to check if the PHP 7 alpha worked at all on my machine. What if the Apache problem was a misreport, and PHP itself wasn't working? I dropped down to a command prompt and tried to serve up my phpinfo.php (which does exactly what it sounds like) file. And, lo, I got this:



Aah... right. They've used a different version of Visual C++ to compile the alpha (ooh... keyword density... I mean "PHP 7 alpha") than they did the dev releases. Groan. Maybe this was documented somewhere, but nowhere obvious enough for me to have noticed. FFS (see the bottom of the article for an admission about this, btw).

Google "php7 VCRUNTIME140.dll"... and I quickly found this: "PHP7 : Missing VCRUNTIME140.dll" (closed as "off topic". You're f**wits, Stack Overflow. You really are). This linked through to a 32-bit version of the file, but that's no help to me (yeah, I still tried it. No). I need the x64 one. More googling. The 32-bit file was called "vc_redist.x86.exe", so I googled "vcredist_x64.exe 2015". I learned to add the "2015" because if I didn't I was getting matches for 2008 and 2013 and everything else. The second match for that too me to here: "Visual C++ Redistributable for Visual Studio 2015 RC", and I downloaded the 64-bit version: vc_redist.x64.exe.

I installed that, and restarted Apache. And it started.

So now when I hit my phpinfo.php file, I see this:


Cool.

All in all it took me longer to write this article than it did to work out how to sort it out. I reckon it was about 2.5 hours in total.

But...

Remember my gripe about not being told I needed the C++ distributable. Well [cough] [ahem]... If I actually took the time to read the sidebar on the download site, I'd've noticed this:


- The VC14 builds require to have the Visual C++ Redistributable for Visual Studio 2015 x86 or x64 installed

AAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHH!!!!!!!!

OK. Mea culpa. I don't mind feeling like a dick, but I'll mitigate this slightly with this observation: that info is presented in completely the wrong place. The downloads don't work without the relevant redistributable installed, so I really think it should be promoted front and centre, next to the link for every download. Or at the top. But not in a sidebar, which is - by definition - a sidebar. Basically: tangential shit you can basically ignore. Well: lesson learned. RTFM, Cameron.

If anyone else is as unobservant as me, perhaps they'll at least find this article detailing what to do to get the frickin' thing working. Now... back to the Guinness...

--
Adam
Posted by at
Labels: ,