Mac OS X Server v10.6.3 Update is not PHP Neutral

| | Comments (1)

Mac OS X Server v10.6.3 Update installs Apple’s PHP v5.3.1 over your custom install.

If you used sudo make install before, just do it again. I can’t see that Apple did anything particularly unusual with their PHP build. Just don’t forget to sudo mv php.dSYM php in /usr/bin because of the screwy results of make install.

Your mileage may vary, of course, so proceed with caution.


Bill Eccles said:

One reader, who tried to comment and failed (thanks for the clue--I'll look into it) had this to say:

"I'm not sure that they are stomping on anything that doesn't belong to Apple. Your problem is self inflicted, you shouldn't specify /usr/as the location to install php. Use /usr/local/ and then you have 2 installs of PHP & you simply choose which one you want to use & Apple can do whatever they please without affecting you.

"A decent description is here…

"It is mentioned in Tim's comment on your site too…

"Thanks, Drew"

Both Drew and Tim are correct that I can indeed put my own PHP binary somewhere else. But I have three objections.

The first objection is that I don't like having parallel installations. Yes, it makes dealing with Apple's updates easier, but only sorta'. If I put the CLI PHP in /usr/local (and there's some valid debate over where that's a good place to put it or not, but it's irrelevant for the moment--suffice it to say "somewhere else" is the destination), then I could be left wondering what version of php I'm running when I instantiate it from the command line. Hence when I update my PHP, I move the Apple binary aside and call it Now I know that I'm using my PHP build and not theirs, but keep theirs just in case.

If your argument against that is, "Well, I have to type in /usr/local/php because /usr/local isn't in my PATH," then I submit that I don't like to type quite as much. And if /usr/local were in my path, I'd lead myself to confusion very quickly.

So I just like to put PHP where it belongs and is expected. It keeps me sane, though that is counteracted by having to update it each time Apple overwrites it. I picked my poison...

The second objection, which is related to the first, is that what to do with the PHP CLI binary is only part of the problem. The other part is trying to solve what to do with "", the Apache module loaded as specified in /etc/apache2/httpd.conf. It lives in libexec/apache2/. First, most people don't know that libexec is in /usr. Well, I didn't until right now, or didn't remember that, anyway. Second, you have to know to use "--libexecdir" in the ./configure stage of things. I didn't know that existed until just now, either. Third, you have to change your httpd.conf to point to the different location, either with the Server Admin app or manually. (Server Admin seems to respect that change according to httpd.conf itself.)

But now I'm changing two things. I find it hard enough to remember that I did one thing, much less two. It really seems easier to me--and that's a big "to me"--to do it my way. This discussion has reminded me, though, that I don't make a backup copy of Apple's module. I'll change my ways.

The final objection is, well, what is the definition of "belongs to Apple?" It is reasonable to expect that server gurus and others, like me, are going to mess with PHP--it's a given, I'd say. I don't really think the PHP in /usr belongs to Apple inasmuch as there are all kinds of things that you can compile into and out of PHP. If Apple really wanted us to stay out from under that particular hood, I think they'd make it clear somehow (as if overwriting PHP weren't enough...).

Both of you--thanks for the input! I will update my PHP tutorial with a caveat at some point.