What Jessie Did Next...

...being the inane ramblings of a mundane Yorkshire bird.

While developing a site which did some image resizing, I noticed this morning that Apple’s version of php5 which is shipped with Leopard didn’t have this library available! It does seem a rather odd omission, given that it’s probably one of the most commonly-used libraries behind mysql/mysqli.

A quick Google revealed that I’m not alone in this, and indeed Apple Discussions has threads on this particular subject albeit for Leopard Server (I’m running the bog-standard desktop edition). After trying a few solutions, I found that the Hill’s Dorm tutorial on installing GD gave the best pointers.

There are a couple of gotchas:

  • Don’t use the Darwinports version of libjpeg – it’s a 32-bit version. This wasted half an hour while I tried to work out what was wrong only to find that I had the 32-bit libjpeg installed when everything else (including php5 and apache2) were 64-bit; the instructions given on the tutorial above does tell you how to build 64-bit versions of things which any recent Intel MacBook will require. A telltale sign of this is seeing in your logs: PHP Startup: Unable to load dynamic library ‘/usr/lib/php/extensions/no-debug-non-zts-20060613/gd.so’ – (null) in Unknown on line 0 if you’ve got the wrong architecture (you might also see architecture errors in config.log if you’re really mismatching stuff).
  • Don’t assume it’s not working because the command-line edition doesn’t work. This had me foxed and indeed seems to be that the CLI version of pph5 which Apple supply hasn’t got the capability to load dynamic libraries. The error is along the lines of dyld: Symbol not found: _php_sig_gif and puts the CLI version of php out of action pretty much.

I’m sure a more elegant solution will be along sometime, but for the moment this does seem to work.


  1. Niels van Hoorn

    April 21, 2008 at 9:23 am

    I’ve had the same errors on my 32-bit MacBook Pro, but founs a bit of a hack to make the command line work again.

    You still can’t use any extensions, but on the other hand, you don’t have to compile anything too. And as I use the CLI of php only for validating syntax, it works for me.

    What I’ve done is use the -c option of the php cli to load another configuration file. In this configuartion file you comment out the extensions, so php won’t try to load them. So in steps (note: most of these require root access, so if you aren’t root, put sudo in front of them):

    * cp /private/etc/php.ini /private/etc/php_cli.ini
    * Edit /private/etc/php_cli.ini and remove or comment out every line that starts with ‘extension=’
    * Create an alias in your ~/.profile to use this php_cli.ini on the cli. Add the following line to your ~/.profile: "alias php=’php -c /private/etc/php_cli.ini’" (without the double quotes)
    * type "source ~/.profile" to reload you profile.

    This also works with the PHPfr widget (http://andrew.hedges.name/w…), just put "/private/etc/php -c /private/etc/php_cli.ini" in the configuration field on the backside of the widget.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.