Mac OS X Server v10.6.3 Update is not PHP Neutral
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.
Tags:
1 Comments
Search
Tag Cloud
- 10.10
- 10.9
- Air Travel
- Another Take
- Aperture
- Apple
- AppleScript
- AppleTV
- Aviation
- Bill
- Cancer
- China
- Christianity
- Christmas
- Conservative
- Cycling
- Dogs
- Dumb Design
- Economy
- Ego
- Election 2008
- Election 2010
- Election 2012
- Energy
- Engineering
- Four Word Movie Review
- Four Word Reviews
- Fun Stuff
- God
- Government
- Grammar
- H.
- Healthcare
- Humor
- Internet
- iOS
- iPad
- iPhone
- iTunes
- Liberal
- Mac App Store
- MacOS X
- MacOS X Server
- Mavericks
- Medicine
- Microsoft
- Mr. Bill Goes to Washington
- Music
- Nobama
- Note to Self
- O.
- Observations
- Opinion
- Parenting
- Partial Fractions
- PHP
- php
- Politics
- Programming
- Puzzles
- Random
- Random Thoughts
- Rant
- Review
- ROS1
- Safari
- Sermon Starter
- Signal
- spam filter
- Spamhaus.org
- T.
- Tech
- Tolland
- Tools
- Translation
- Travel
- Vacation
- W.
- Weight Loss
- WTF?
- Xserve
- Yosemite
Archives
- November 2024
- November 2022
- May 2022
- November 2021
- August 2021
- February 2021
- December 2020
- October 2020
- September 2020
- May 2017
- November 2016
- July 2016
- May 2016
- July 2015
- May 2015
- March 2015
- January 2015
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- January 2014
- December 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- July 2007
- January 2007
- December 2006
- November 2006
- October 2006
- April 2004
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… http://hivelogic.com/articles/usingusrlocal
"It is mentioned in Tim's comment on your site too… http://www.bill.eccles.net/bills_words/2010/01/building-a-mac-os-x-server-106.html
"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 php.apple. 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 "libphp5.so", 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 libphp5.so 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.