Configuring PHP on OS X Leopard: the Gritty Details (Part 2)

This is the second part of a series which reviews in-depth the process of building a PHP environment on OS X Leopard.  Please read Part 1 of this series before continuing.

A Little about PHP
Before building anything new, let’s look at what we already have.  OS X Leopard comes with PHP already installed as both the command line executable (from now on referred to as CLI) and as an Apache shared module.  

The PHP CLI and the Apache module of PHP are completely separate versions of PHP. 

Neither requires the other to function. You can generate one and not the other or both at the same time.  The reasons behind the two seperate versions is simple:

• The CLI can be used in place of Perl, Bash, or any other scripting language for writing applications that run on the command line.  There are even extensions where you can put a GUI on a PHP application for use on a graphical desktop. Example: If you need to write a script for routine maintenance of website, like indexing your post or something, you can write a PHP CLI application and have cron execute it every day.  Now I don’t need to learn another script language for basic Unix admininstrative tasks!
• PHP is still primarily used for web programing on, specifically on Apache web servers. 
  While can use the CLI version of PHP via CGI, having a version of PHP that’s a module of Apache provides better performance.  This Joomla article provides a pretty good explanation of the the differnet reasons you may choose to use CLI or Apache module for a webserver.

You’ll find the CLI by default /usr/bin. Try checking the file information (note that the ‘$’ is the command prompt and should not be explicitly typed):

$ file /usr/bin/php

You’ll see that the installed version is 32-bit.  The Apache shared module is found in /usr/libexec/apache2/.  Looking at this file we see something different:

$ file /usr/libexec/apache2/libphp5.so

Like the libraires in /usr/lib/, this libphp5.so is compiled as a univeral binary.  This is needed as it has to work with Apache and httpd has been compiled as both 32 and 64-bit (which you remember from the first part of this series).  Now’s probably a good time to move on to libraries.

C Libraries
Like many terms when dealing with programming, the word library get overloaded.  In the case of building a PHP environment, libraries usually refers to C libraries. C Libraries are files that can be linked with your code to provide functions, classes, and data.  They provide a way to share functionality and allow reuse of common code.  There are 2 basic types of C libraries: static and dynamic.  Static libraries are compiled into your program.  You can tell a library is static by it’s extension (‘*.a’).  Dynamic Libraries on the other hand are kept separate from your program and have the extensions (‘*.dylib’ or ‘*.so’).  When you compile a program, the compiler inserts references to the Dynamic Libraries not the actual code from the libraries.  When you run the binary executable, the operating system goes out, finds the referenced libraries and links them to the executable.

For example, the CLI is a binary executable.  When you build the CLI, if you associate it with a static library, the necessary code from that C library will be copied into the final CLI binary that’s created by the compiler.  If you later were to delete the library, everything should still function with your CLI.  However if you build CLI with dynamic libraries, if you move, rename, or delete a shared library, the CLI program will complain or possibly fail to run.

Why use shared libraries?  Well, when libraries get updated and new versions come out, you have to recompile every executable binary that are tied to that static libraries as the library is now hard-coded into these executables.  If you use dynamic libraries, you just update the library and every program that uses that library will benifit (of suffer if the library has a bug or it’s built incorrectly).  You can get more details regarding libraries Here.

Libraries are typically stored in common places like /usr/lib/ or /usr/libexe, but can be placed anywhere on the system.  We’ll be putting all the libraries we create in our own isolated folder.  That way we can be sure we know exactly where, ensure the version we want, and don’t have to worry about Apple Updates overwriting our hard work.

Here’s a manta that should be memorized.

You can’t compile a 64-bit executable with 32-bit libriaries, or vice-versa.

This is probably the where most problems occur when dealing with libraries/extensions and PHP.  Based on what we now know from Part 1 of this series, the way we’re going to get around this issue is to utilize OS X Universal Binary feature.  That way, every library we add to the system whether you have a 32-bit or 64-bit setup.

You should now have a pretty good understanding of the basics you need to start putting things together.  In Part 3 we’ll put this all together to start building the necessary component!