Bill Eccles: January 2010 Archives

When Art Fisher of In Color had some problems with my instructions for installing PHP, he and I dove into finding the solution.

Here’s what we came up with, and instead of publishing a new article, I just amended the old one.

I just noticed on my 10.5 server that it installs PHP 5.2.11 over your custom installation for 10.5 boxes. See here for more info.

I had one minor problem when installing 5.2.12 on my 10.5.8 box, and that is because of a gripe caused by multiple conflicting values in some header files which are both pulled in for the build. If you have this problem, it’ll look like this:

In file included from /usr/include/arpa/nameser.h:59,
                 from /Users/admin/Installed/php-5.2.12/ext/standard/dns.c:62:
/usr/include/arpa/nameser8_compat.h:304: error: conflicting types for 'HEADER'
/usr/include/arpa/nameser_compat.h:99: error: previous declaration of 'HEADER' was  here
In file included from /usr/include/arpa/nameser.h:59,
                 from /Users/admin/Installed/php-5.2.12/ext/standard/dns.c:62:
/usr/include/arpa/nameser8_compat.h:304: error: conflicting types for 'HEADER'
/usr/include/arpa/nameser_compat.h:99: error: previous declaration of 'HEADER' was here
In file included from /usr/include/arpa/nameser.h:59,
                 from /Users/admin/Installed/php-5.2.12/ext/standard/dns.c:62:
/usr/include/arpa/nameser8_compat.h:304: error: conflicting types for 'HEADER'
/usr/include/arpa/nameser_compat.h:99: error: previous declaration of 'HEADER' was here
In file included from /usr/include/arpa/nameser.h:59,
                 from /Users/admin/Installed/php-5.2.12/ext/standard/dns.c:62:
/usr/include/arpa/nameser8_compat.h:304: error: conflicting types for 'HEADER'
/usr/include/arpa/nameser_compat.h:99: error: previous declaration of 'HEADER' was here
lipo: can't open input file: /var/tmp//ccqI3ov4.out (No such file or directory)
make: *** [ext/standard/dns.lo] Error 1

To rectify that problem, create a file called patchfile and paste the following text into it.

*** ext/standard/dns.c       2009-10-16 18:09:49.000000000 +0200
--- ext/standard/dns.c    2009-12-17 18:10:55.000000000 +0100
*** 56,63 ****
--- 56,65 ----
  #undef T_UNSPEC
  #include <arpa/nameser_compat.h>
+ #endif
  #include <arpa/nameser.h>

(I got the code above from this bug filed on

Then do patch <patchfile followed by the usual configure/make/make install cycle described in this post (for example). You should be back in business.

This chart is rather interesting. It compares the various markets of two juggernauts in the world of electronics and web presence, Google and Apple, and… Yahoo… which is pretty much a has-been.

While interesting, I think that’s not a really great comparison. While Google may want to be everything Apple is (and seems to be headed that way), Apple doesn’t want to be everything Google is. Furthermore, Steve Jobs doesn’t want to be Eric Schmidt/Sergey Brin/Larry Page/whoever. They might want to be him, but not the other way around.

So, if I had to pick someone that Steve Jobs might aspire to achieve parity with (if he doesn’t already think of himself as being at the top of the heap), it would be Sir Richard Branson.

Interestingly, Virgin is a $9.6 billion company, and Apple is a $50+ billion company.

I’m not exactly sure why I think this. Perhaps it’s because much of what Virgin does, Apple does: entertainment and mobile services. Maybe it’s because Steve is rich enough to begin investing in other enterprises that are closely tied to his interests. Goodness knows, an Apple airline would be an interesting item. Of course, he would never do that because he couldn’t control the whole widget, which includes TSA, in order to make the entire flight experience a Jobsian one.

Anyway. Just thinkin’ out loud.

Can we expect to hear Osama Bin Hidin’ take credit for this one, too?

iPad... iWant!


A recent article in USA Today says that China is trying to promote itself as a wonderful place to have your products manufactured.

I’m guessing that these won’t be themes throughout the campaign:

China: Our laborers are underpaid, so your prices are low!

China: We copy your intellectual property so Chinese companies can make products more affordable so our underpaid laborers can afford them!

China! China! China! (It sounds so much better when 50,000 workers chant it in gratitude to the Motherland.)

China: Making lots of cheap crap so you can buy it because you’re too cheap to buy American.

China! You don’t have a choice but buy our stuff because you’ve demanded lower and lower prices and to remain competitive, the companies you have been forced to offshore their production to us, because that keeps your prices down. Yay, China!

Made in China! Now displayed proudly on the front of the product, too!

It all came to me last night in a dream about the product announcement. Let me describe the new and innovative interface that Steve himself showed me:

At the top of the screen will be a menu bar. I remember “File” being on there. To use the “File” menu, you simply touch it and drag down. As you do, a 26-letter menu appears, much like a vertical keyboard. This allows you to drag each letter of the command.

To open a file, you would merely drag your finger around from the “O” to the “P” to the “E” to the “N” tiles. That’s it! So simple that anybody who can remember what is supposed to be under the “File” menu can use it!

Of course, the fact that Steve was dressed as a nerd and the whole announcement took place in the bleachers of a school gym make me a little suspicious of the quality of the revelation.

Instead of publishing a completely new entry here, I’m merely going to say that if you want to know how to add FreeType support to PHP, then go have a look at the old entry, which I’ve amended with instructions for adding FreeType.

Since I'm a bit behind on testing Mac OS X Server updates, here's the scoop, many moons late: Server Security Update 2010-001 breaks PHP custom installations.

Apple installs PHP v5.3.0 over your custom PHP installation.

Here's what I did to alleviate the pain associated with the upgrade:

Before I upgraded, I backed up my configuration information (which I can use to reconfigure PHP if necessary) and current PHP installation so I can downgrade in a hurry if I can't rebuild the new PHP quickly:

php -i > ~/php-config-2010.01.20
sudo cp /usr/libexec/apache2/ /usr/libexec/apache2/
sudo cp /usr/bin/php /usr/bin/php.old

I then did the update, which on two machines, one client and one server, left the machine hanging with a blue screen and the spinning gear. Forcing a restart seemed OK, and there were no log gripes to speak of.

If I were very concerned that PHP weren't working correctly and quickly, I'd have swapped the newly-installed Apple PHP with the old one and set it to running while I rebuilt PHP. I didn't need to do that, though, so I just proceeded with rebuilding and reinstalling 5.3.1.

Once the update was done, I looked at what Apple used to configure php...

php -i

...and noticed that it wasn't all that unusual. I then backed up the Apple stuff...

sudo cp /usr/libexec/apache2/ /usr/libexec/apache2/
sudo cp /usr/bin/php /usr/bin/php.old

...and grabbed the 5.3.1 PHP tarball from, php-ized GD, configured it, made it, and installed it per these instructions.

I then restarted Apache2 with Server Manager and PHP5 was happy again.

I’ve been having wicked-bad performance problems with VMWare Fusion 3.0—the frustrating, I-want-to-hurl-it-through-the-Windows kind of performance problems. Turns out it’s a combination of v3.0 of Fusion and AVG Free 9.0

Since we changed antivirus protection types from a site license to a pay-per-copy license, I had to change to a free antivirus checker, and chose AVG Free 9.0. After that, performance went downhill. Windows would crawl along (refreshes were slow, sometimes not occurring at all), usually after resuming a VM, one core would jump to 100% usage, and Windows thought life was hunky dory because it shows 0% CPU usage. I.e., Fusion was working very hard, even though Windows was not. Weird.

Turns out, it’s a known problem with v3.0 of Fusion and AVG Free 9.0, and if I’d bothered to read the release notes, I’d have never chosen AVG Free. After uninstalling AVG Free and installing avast! antivirus, which got good reviews from reputable sources, the problem has gone away.

Hope that helps someone…

Very dark, but fascinating.

(Loved the music, too.)

Amazing. Courtesy of Gruber at, I just signed up for the beta of HTML5 video playback on YouTube. You can, too. Just click here. Don’t be afraid, “beta” is not as bad as it sounds. It’s just a Google codeword for… for… well, nobody’s really sure.

Is it worth clicking through to sign up for this beta? If you use Safari or Chrome on a Mac, the answer is not just Yes, but rather Heck, yeah! I just watched a short video with this new playback method and my laptop barely broke a sweat. Watching a YouTube video with Adobe Flash causes my laptop to break out in tears begging for mercy, for me to put an end to it before it self-imolates under the strain of the bloated framework that is Flash.

If there were any better proof that Apple was wise in its decision not to allow Frickin’-Flash on its iPhone platform, I have yet to see it.

(I also use ClickToFlash as a preventative measure. It makes web surfing so much more palatable, and my laptop loves me for it.)

Here’s a “Sermon Starter,” an idea that I hope proves to be useful to someone in his or her quest to arrive at material for next Sunday morning’s sermon. I’ve occasionally had thoughts—fractional ideas, really—which I have thought would make the basis for a great sermon. But having no pulpit and having not one iota of theological talent, I’m unable to deliver on the goods. So here is a Sermon Starter. Feel free to use it in your message, and don’t hesitate to write your source into your notes.

Our family was reading in Luke 9 last night and the thought occurred to me that there are twelve baskets of leftovers mentioned in verse 17. Interestingly, throughout the Old Testament, the people get just enough. Manna, for example: just enough.

But now Christ has come along and, whammo! Our cup runneth over. Twelve baskets of leftovers. More than enough. A surplus. More than “a portion.”

Interesting, huh?

OK, folks, as you may recall, I got a new server capable of running Mac OS X Server 10.6. Problem is, it doesn’t know jack about my custom PHP or Perl installations on my 10.5 server, so I have to figure out what to do to setup these things again. Let’s go!

What did I do before?

First, what did I have installed last time? Well, let’s start with the applications I use. First, there’s Gallery. Then there’s Moveable Type, which is what you’re using right now to read this ‘blog. And I have a weather collection app that runs in PHP. Each of these has its own requirements:

Gallery requires a bit of stuff:

  • a database—check! That’s MySQL.
  • an image processing library—check? Previously, I used ImageMagick, but I note that Gallery 2 now supports GD, and, as we’ll see later, I’m using GD for other things. So perhaps there’s some (ahem) synergy to be had here. Keep GD at the top of the list, ImageMagick if required.
  • mod_rewrite—should be a checkbox in Server Admin, so let’s hope it is.
  • ffmpeg
  • dcraw
  • jhead
  • infozip—I’ll skip this one.
  • zip—probably check?

MT requires no extra PHP goodies, but has a pretty good list of Perl modules that are optional in addition to a few that are required. From the requirements page, we get this list:

Required Perl modules

  • CGI
  • Image::Size
  • File::Spec (Version 0.8 or higher)
  • CGI::Cookie One of the following Database Perl Modules is required:

  • DBD::mysql (version 2.9005 or higher) - When using MySQL database

(This is what I’ll use, so I ignore the others.)

WARNING: DBD::mysql 2.9004 is not recommended nor supported by Six Apart due to the error: “Statement has no result columns to bind”. Later versions of DBD::mysql are recommended.

Optional Perl Modules

The following Perl modules support option functions. Use these modules for even greater functionality with Movable Type.

Archive::Tar Archive::Zip Crypt::DSA Crypt::SSLeay Digest::MD5 Digest::SHA1 File::Temp GD HTML::Entities HTML::Parser Image::Magick IO::Compress::Gzip IO::Socket::SSL - New in MT5 IO::Uncompress::Gunzip IPC::Run List::Util LWP::UserAgent Mail::Sendmail MIME::Base64 Net::LDAP - New in MT5 Safe Scalar::Util SOAP::Lite (Version 5.0 or higher) Storable Text::Balanced (Necessary for searches within a blog) XML::Atom XML::Parser XML::SAX

And my own weather application requires only JpGraph, but it needs

  • GD
  • FreeType 2.x and
  • the fonts for FreeType to use.

The big, burning question in my mind is, What has Apple enabled in the default PHP installation? Used to be that GD was off by default, as was FreeType. Let’s issue a php -i to find out:

$ php -i

Holy crap. In the output on this 10.6.2 box, we find


GD Support => enabled
GD Version => bundled (2.0.34 compatible)
GIF Read Support => enabled
GIF Create Support => enabled
JPEG Support => enabled
libJPEG Version => 6b 
PNG Support => enabled
libPNG Version => 1.2.37

Amazing! This was a long-standing gripe I had, and the result is that I don’t need to do anything fancy… just yet. But is everything else there?

In any case, first step: grab Xcode and install it. Then don’t forget to turn on CGI execution and the php5_module in Server Admin.


Now let’s do something simple and make JpGraph work. (A few hours of frustration pass… and I’m not kidding. It’s so simple, and yet sometimes, so hard.) It’s really rather simple.


First, grab the tarball for JpGraph. Extract it. In my other installation, I had decided (for some odd reason) to put the scripts in the root directory of the weather site, but upon reading the installation notes, I decided to locate them a little more sensibly. So I moved/renamed src to /Library/WebServer/CGI-Executables/jpgraph like this:

$ cd jpgraph-3.0.7
$ mv src /Library/WebServer/CGI-Executables/jpgraph

and changed the ownership and permissions so that it can be used by the webserver user (which is in the group _www):

$ cd /Library/WebServer/CGI-Executables/
$ sudo chown -R admin:_www jpgraph
$ sudo chmod -R 755 jpgraph
$ xattr -dr jpgraph

Then I moved the Examples folder to the root Documents folder (because I have no sites up at this point):

$ cd jpgraph
$ mv Examples ../Documents/

And then had to make a symbolic link in the Examples folder so that the examples can find the jpgraph directory.

$ cd ../Documents/Examples
$ ln -s  ../../CGI-Executables/jpgraph/ jpgraph

I then pointed my webbrowser to http://localhost/Examples/testsuit.php and, Yes! I have graphs! There are some gripes about PHP with no support for TTF. And this is where things get interesting because what we have to do now is rebuild PHP from scratch, ensuring that we get TTF—as well as all of the other things that Apple includes, plus the stuff we need for other applications—built into it.

That’s a bit tricky, and we have to break down the configure line that Apple used in order to see what libraries we have to make.

PHP, Just Like Apple

Let’s try to build PHP just the way Apple builds it, with their configurations ‘n’ all. If you look at the output of php -i, you can see what Apple used to build the PHP installation distributed with Mac OS X Server 10.6.

Configure Command =>  '/var/tmp/apache_mod_php/apache_mod_php-53~1/php/configure'  '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--sysconfdir=/private/etc' '--with-apxs2=/usr/sbin/apxs' '--enable-cli' '--with-config-file-path=/etc' '--with-libxml-dir=/usr' '--with-openssl=/usr' '--with-kerberos=/usr' '--with-zlib=/usr' '--enable-bcmath' '--with-bz2=/usr' '--enable-calendar' '--with-curl=/usr' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/BinaryCache/apache_mod_php/apache_mod_php-53~1/Root/usr/local' '--with-png-dir=/BinaryCache/apache_mod_php/apache_mod_php-53~1/Root/usr/local' '--enable-gd-native-ttf' '--with-ldap=/usr' '--with-ldap-sasl=/usr' '--enable-mbstring' '--enable-mbregex' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-mysql-sock=/var/mysql/mysql.sock' '--with-iodbc=/usr' '--enable-shmop' '--with-snmp=/usr' '--enable-soap' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-xmlrpc' '--with-iconv-dir=/usr' '--with-xsl=/usr' '--with-pcre-regex=/usr'

Before I forget—we won’t be doing the standard make/make install without first backing up the php binaries. I had problems making sure that the architectures of my Apache server and the PHP binaries matched, and if they don’t, Apache won’t load them. And then Apache won’t load and your webserver is borked pretty good until you get PHP working perfectly. With that in mind, onward!

The first thing to do is, of course, grab the PHP tarball from its source and unsmoosh it. I tend to keep all of this stuff in a new folder, Installed, in my home directory, by the way.

Ideally, we’d just do the configure command just like Apple. Given that it’s easy to download Xcode and PHP and try it all out on the laptop as I’m writing this, I decided to just dive right in and try the configure command as Apple did it and see what it gripes about. (Copy and paste the original Apple configure command to your command line, then edit out the /var/tmp/Apache… bit so that it’s just ./configure.)

The first thing it gripes about is not being able to find the PCRE headers file.

checking for PCRE headers location... configure: error: Could not find pcre.h in /usr

That’s because this option


is telling Configure to look for pcre.h where it just won’t find it. I Googled it and discovered that there are all kinds of fixes out there that involve copying a file that doesn’t seem to exist into somewhere else so that it can be found. Hmm. That doesn’t sound like the right approach. And Apple has a patch that doesn’t seem to work, either because it’s targeted at an older version of PHP (5.3.0) or because they place a libpcre somewhere that we don’t have it in a clean installation.

After a while of digging, I realized that some of the advice out there on the web is merely to copy the header file from php-5.3.1/ext/pcre to /usr/somewhere. Wha…? Why copy this file if it seems like the normal PHP installation has PCRE built in as an extension, i.e., no library needed, it’s self-contained in the installation? Then all we have to do is something like we do with GD, namely just say “Yes! I want PCRE!” and don’t worry about where it comes from.

(By the way, downloading and installing libpcre also works. But that’s overkill at this point, and it may introduce problems with PHP because the current PCRE is 8.0 and the one installed with PHP is 7.8, I think.)

So if you change the flag above to this:


the problem goes away and configure reports

checking which regex library to use... php

Whew. Now, on to other problems, because there are some, specifically:

configure: error: libjpeg.(a|so) not found.

These flags cause that particular problem:


There’s a big problem: we don’t have the mythical /BinaryCache/apache_mod_php... directory, so we have to make our own jpeg lib and png lib. Ready for that? Thought so! Let’s go!


First, grab the libjpeg tarball from its source. Then extract it and throw it into your Installed directory or wherever you’re keeping all this stuff, and it’s important to keep it because as often as Apple wrecks custom PHP installations, you are going to have to do it all again someday.

Things have gotten a bit easier since I did this last time, about five years ago, and all you have to do is the standard configure/make/make install with one option, like this:

$ ./configure --enable-shared

8< snip!

$ make

8< snip!

$ sudo make install

All we have to do now is keep in mind that libjpeg is now located in /usr/local/lib according to make and can edit the flag appropriately.



Again, grab the source for libpng from its source and unpack it. Let’s see if anything’s changed since I last did this with v1.2.8.

$ ./configure
-bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory

Harumph. Well, according to the INSTALL file, we might want to copy the makefile that lives in scripts and use that. Problem is, after I tried it, I noticed that libpng wants to find libz at ../zlib, where it certainly isn’t. And according to my notes, that’s a problem I ran into before. Here’s how to fix all that:

$ cp scripts/makefile.darwin makefile
$ emacs makefile

(or pico or nano or vi or whatever…)

Change this

# Where the zlib library and include files are located                                                                                                            

to this

# Where the zlib library and include files are located                                                                                                            
# ZLIBLIB=../zlib                                                                                                                                            
# ZLIBINC=../zlib

and save it. You have to do this because Apple has started to include (or has always included?) the zlib library, and it’s not in the /usr/local directory but is with the rest of the Apple-provided stuff in /usr. Then

$ make
$ sudo make install
$ ./pngtest pngtest.png

which should produce a bunch of lines with r’s and w’s. If it does, then, Yay! Continue onward.

The libraries end up in /usr/local/lib, just like libjpeg, so its options look similar:


And now let’s hope for the best.

Back to PHP

If you try again, things should work just fine with the exception of this error:

Notice: Following unknown configure options were used:


Check './configure --help' for available options

We can ignore that one, unless you’re particularly retentive and decide to eliminate it. Otherwise, the complete configure command looks like this:

./configure  '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--sysconfdir=/private/etc' '--with-apxs2=/usr/sbin/apxs' '--enable-cli' '--with-config-file-path=/etc' '--with-libxml-dir=/usr' '--with-openssl=/usr' '--with-kerberos=/usr' '--with-zlib=/usr' '--enable-bcmath' '--with-bz2=/usr' '--enable-calendar' '--with-curl=/usr' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--enable-gd-native-ttf' '--with-ldap=/usr' '--with-ldap-sasl=/usr' '--enable-mbstring' '--enable-mbregex' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-mysql-sock=/var/mysql/mysql.sock' '--with-iodbc=/usr' '--enable-shmop' '--with-snmp=/usr' '--enable-soap' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-xmlrpc' '--with-iconv-dir=/usr' '--with-xsl=/usr' '--with-pcre-regex'

If configure runs OK, then try make. (If you’ve been trying make at various points along the way, don’t forget to make clean.)

It’ll fail. Don’t ask me how I know, I just know. My sources tell me you’ll see:

Undefined symbols:
  "_libiconv", referenced from:
      __php_iconv_strlen in iconv.o
      _php_iconv_string in iconv.o
      _php_iconv_string in iconv.o
      __php_iconv_strpos in iconv.o
      __php_iconv_appendl in iconv.o
      __php_iconv_appendl in iconv.o
      _zif_iconv_substr in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _php_iconv_stream_filter_append_bucket in iconv.o
      _php_iconv_stream_filter_append_bucket in iconv.o
ld: symbol(s) not found

Apparently, the only way to fix the problem that exists in PHP5.3.1 is to edit the file ext/iconv/iconv.c from this (which is down on line 185 or so—don’t mix it up with the first one in the file!)

#define iconv libiconv

to this:

#define iconv iconv

Now try make and see what happens. I think you’ll be pleasantly surprised.

The real litmus test will be to install it. Let’s first backup the Apple PHP and then install ours.

$ php -i > ~/php-config-2010.01.17
$ sudo cp /usr/libexec/apache2/ /usr/libexec/apache2/
$ sudo cp /usr/bin/php /usr/bin/

(When I did the php -i above, it griped with

PHP Warning:  Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in Unknown on line 0

so I edited /etc/php.ini to read

; Defines the default timezone used by the date functions                                                                                                         
date.timezone = America/New_York

All of the choices for date.timezone are at the URL shown in the .ini file.)

Now to Add FreeType…

…tomorrow. That’s enough for one day.

Updated! Here’s how to add FreeType (and fonts)

It turns out that adding FreeType support is very easy. First, make sure you install X11 support when you install Mac OS X Server. Then all we have to do is change our configure command with one additional switch. It ends up looking like this:

./configure  '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--sysconfdir=/private/etc' '--with-apxs2=/usr/sbin/apxs' '--enable-cli' '--with-config-file-path=/etc' '--with-libxml-dir=/usr' '--with-openssl=/usr' '--with-kerberos=/usr' '--with-zlib=/usr' '--enable-bcmath' '--with-bz2=/usr' '--enable-calendar' '--with-curl=/usr' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--enable-gd-native-ttf' '--with-ldap=/usr' '--with-ldap-sasl=/usr' '--enable-mbstring' '--enable-mbregex' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-mysql-sock=/var/mysql/mysql.sock' '--with-iodbc=/usr' '--enable-shmop' '--with-snmp=/usr' '--enable-soap' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-xmlrpc' '--with-iconv-dir=/usr' '--with-xsl=/usr' '--with-pcre-regex' '--with-freetype-dir=/usr/X11R6'

Sure enough, after a make clean/make/make install (and restarting Apache), you get TTF support enough for the JpGraph to acknowledge that it is installed, but it will gripe that Arial and Verdana aren’t installed. Which they aren’t. So it’s right.

So how do we go about installing these fonts? Simple! Since we’re using a Windows machine, all we have to do is copy them from Microsoft… oh… wait… that’s a problem, now, isn’t it?

Well, now… all we have to do (for real) is get the core web fonts, which include Arial and Verdana, from Microsoft or somewhere else and put them where Jp Graph can find them. There are two ways that I know of to do this.

  1. Go to the Internet Archive and download each individual file as Microsoft used to distribute them, circa 2002. The page you’re looking for is here. Apparently, that’s how I found them about eight years ago, because I don’t have any knowledge of how to do:

  2. Download the fonts from the Corefonts project. This technique involves downloading a “cab” file (which Microsoft seems OK with) and extracting the contents using some utilities. You might want to just copy the .ttf fonts from some conveniently-available PC.

JpGraph would like to see the fonts in /usr/share/fonts, so all we need to do is create that directory and stick the font files there. I have mine in a folder in my Installed directory, so here’s what I did.

$ sudo mkdir /usr/share/fonts         
$ sudo mkdir /usr/share/fonts/truetype
$ sudo cp * /usr/share/fonts/truetype/
$ ls /usr/share/fonts/truetype/

After that, if all goes well, you’ll be able to load the JpGraph examples and see all the fonts working just fine.

Really, that’s all there is to it…

Updated! Compiling PHP with libpng 1.4.x

Art Fisher of In Color commented below that he had problems with this error during the make when he tried my instructions:

Undefined symbols:
  "_png_check_sig", referenced from:
      _php_gd_gdImageCreateFromPngCtx in gd_png.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1

I had run into that problem, too, and filed a bug against PHP 5.3.1. I guess the guys at consider a bug that they found and fixed in a not-so-public version of PHP (a nightly build of about a month ago) “bogus,” so they marked my bug as “bogus.” I’d have preferred “closed,” but semantics aside, the problem above is caused by the removal of the long-deprecated _png_check_sig from libpng as described in the release notes, here.

Art and I worked together to figure out what was going on and discovered that if you edit line 148 of ext/gd/libgd/gd_png.c from

       if (!png_check_sig (sig, 8)) { /* bad signature */
                return NULL;


       if (!png_sig_cmp (sig, 0, 8) == 0) { /* bad signature */
                return NULL;

PHP will compile fine.

He then found some other problems, one of which you’re most likely encountering and for which I’ll share the solution below.

Updated! PHP not installing a CLI binary

After you’ve done all of that stuff above, you’ve probably fired up your web browser and run a simple phpinfo() script and discovered that you did indeed succeed.

To show off your command-line prowess to you spouse (who will be suitably impressed when you say, “Look, Dear! I successfully compiled and installed PHP version 5.3.1!”), you do a php -i which shows that you didn’t succeed at all! Instead, php -i reports that the old version, compiled by Apple, remains! I looked, and sure enough, the old version of php remained untouched, but there was a strange, and very functional, php.dSYM file sitting right next to it in /usr/bin.


After Googling a bit, I discovered this web page which describes an esoteric problem that the libtool has in Leopard, and now in Snow Leopard, where gcc can’t seem to fully optimize PHP without mis-generating a .dSYM file. Or something like that. That guy on that page describes a way to not-quite-fully-optimize PHP and avoid the problem. Others have described a simpler way to solve the problem which yields a fully-optimized PHP. All you have to do is symlink php to the php.dSYM file.

In case you haven’t moved the old php out of the way yet (in which case that php -i above wouldn’t have worked in the first place), do this

$ sudo mv /usr/bin/php /usr/bin/

then this to make the symlink:

$ sudo ln -s /usr/bin/php.dSYM /usr/bin/php

That way, if you reinstall PHP again (as Apple has a tendency to step on our custom PHP installs, you’re certain to do so…) the newly-created php.dSYM will still link to php commands. Furthermore, if Apple does decide to fix the libtool/gcc problem, then php will be replaced and the problem goes away anyway.

Another Error: Warning! dlname not found in /usr/libexec/apache2/

If you see this

Warning!  dlname not found in /usr/libexec/apache2/

in the middle of the make install step, and yet PHP seems to work fine on both the command line and via Apache, as best Art and I can figure out, it’s OK. Don’t worry.

Updated! Libpng Header Version Problems

If you did what I did and installed libpng 1.4.x, then you have had this problem and probably don’t realize it. When you compile PHP and point it at /usr/X11R6/inclde to pick up the FreeType headers, it also picks up an old, 1.2.x, version of the libpng headers, but still builds PHP with the new version of the library itself, which is in /usr/include. And that’s a problem.

I’ve not been able to figure out how configure decides where to find what, nor how it could even be directed to do otherwise, but my workaround was to do

$ sudo mv /usr/X11R6/include/png.h /usr/X11R6/include/png.h_old

on a temporary—or maybe permanent—basis. I’m not sure I’ll ever need to do anything “real” with X11, so I think it’s OK to leave it that way. But, if you’re, er, retentive about things, you’ll want to put it back when you’re done making a new PHP.

By the way, I will be creating a new entry real soon now that summarizes all of these steps because as I’m doing it fore real, I realized it’s a real pain to read through the narrative to get to the heart of the process.

Worth a click through:

Space Shuttle Deals

A New Server!


Well, folks, my dad decided to really splurge and bought our family a new-to-us Intel Xserve. A “Late 2006” model with four cores of Xeon power, it does hum along. Speaking of hum, this puppy sounds a lot like a jet plane when it’s running full bore. Fortunately, it lives in the well-insulated computer room where finding it just the right spot has been somewhat difficult. It is a big box, after all, about the thickness and width of a pizza box, but about twice as deep. Try finding counter space for two large pizzas and you’ll have some idea of the challenge. I’m a creative kinda’ guy, though, so I’ve found a solution that works nicely and will actually reduce the apparent space taken in the room by the various computers.

So far, the only problem I’ve had is trying to find disks for it. The Apple Drive Modules for this box went out of production a long time ago, and woe to the sysadmin who needs a new one! No worries, though, as the box has two FIreWire 800 ports and two USB 2.0 ports. And if I ever want “faster,” I’ll put in a eSATA RAID controller. But in the meantime, the USB 2.0 will do. (Strangely, most of my drives’ FireWire 400 controllers are toast, causing bus resets at an alarming rate. I’ll stick with USB 2.0, which is plenty fast for serving the files around the house.)

What does this mean for you? Well, the best part of the deal was really the price, since we got this box for $1700 with a copy of Mac OS X Server 10.6. w00t! I’ll be able to continue updating you on whether Apple destroys your custom PHP installs… as soon as I get my own custom PHP install put in.

That’s this morning’s project, and I’ll let you know how it goes.