PHP on Leopard Redux

In Installing PostgreSQL on Leopard I talked about building a 64-bit version of PostgreSQL on Leopard. On or about September 12, 2009 Apple released a “security update” that required a re-boot. Routine stuff. Could have been a new version of iTunes for all I knew. (Maybe it was, doesn’t matter.) All I know is that I got email from a student saying my course schedule page was coming up mostly blank.

After some sleuthing, I found that the problem was a little piece of PHP code that was displaying the subject and timestamp of the latest post from the PHPBB forum for the course. Nobody uses the course forum, at least not at this point in the semester, so I commented out the XML snippet that causes the schedule generator to put in the status message. Until I could track down the real culprit, which turned out to be that PHP did not understand PostgreSQL databases any more. That meant that a real site was broken: I haven’t converted the application form to put applications directly into the database, but the page that shows all the committee seat holders was hosed. PHP had no idea what this funny pg_connect() function was. That latest Apple update had silently installed a new version of PHP without telling me. And of course their PHP doesn’t know about PostgreSQL: I had added that to the system myself without telling Apple that I would like to be informed when they decide to clobber my system. My Bad, not Apple’s. Oh no, not their fault that I should decide PostgreSQL suits my purposes better than MySQL.

So I downloaded the latest version of PHP (5.3.0) so I could re-build it with PostgreSQL support. This actually looked like a fortuitous situation: I had just used some new DateTime functions that were introduced in PHP 5.3.0, and this would save me the trouble of coding around them when running on the old PHP 5.2.x stuff on babbage. I had just done this on my laptop with no problem, so it should have been a piece of cake. Except the build failed with loud wailings about libiconv. So I downloaded libiconv 1.13, built it, and installed it. To make a long story short, I ended up building a bi-versal binary version of libiconv (32 and 64 bit intel), installed in /usr/local/lib. And I removed the version of libiconv in /usr/lib (I could not get the PHP builder to search libraries in the proper order, so this seemed the path of least resistance.) I needed the x86_64 architecture for my 64-bit version of PHP, and I needed the i386 architecture for the 32-bit version of at least tar. So far so good. Until Apple tromps on my system again, of course. Or I find that something else is broken already.

And why does it turn out that httpd is a universal binary? I thought the whole issue was that I had to build 64-bit binaries for PHP and PostgreSQL to be compatible with the 64-bit-only version of Apache that ships with OS X. There must be an Apple resource for people like me who would like to know what’s going on.


When a software update request comes up

When a software update comes up, click on the Details button instead of just blindly accepting it.

Except, of course that you might not get to see the info about the update unless you wait several hours after the software asks to be installed. But by being patient, I can see that security upate 2009-006 is about to bring PHP all the way up to 5.2.12. Woo-hoo! Let's see if I can get Apache to understand that I really want to use my copy of 5.3.0 after I let Apple mess with my system again.

(I have to take the update: it's nagware.)

How to get correct version of PHP after security update

I let security update 2009-0006 run, and sure enough Apache couldn't even start because it couldn't load the php module. I went to the directory where I built PHP, and just did "sudo make install" and waited while it did its thing, including make an update to httpd.config. Apache was thrashing away trying to get going, but picked itself up and ran once I had done the make install. Nothing else to do. It even got the correct CLI version of PHP running again.