Why the PHP5 GD library is insane

For anyone using PHP5’s GD library, you may want to update your copy with the one from the Pirate Repository. By the end of this post, it should be clear why.

At some point along its development, whoever maintains the PHP5 GD extension made a very bad decision: to drop half the extension when linking against external GD.

Now, to go back to the beginning, LibGD is a library for handling graphics. It provides support for a variety for formats and functions, and can support fonts and other crap.

It’s a brilliant library really. The problem is with how it is currently configured in PHP.

Way back when PHP4 was new and dinosaurs roamed the Earth, LibGD was quite limited. The PHP gurus decided to extend it and break compatibility with the main LibGD tree. The solution was to pack in their own LibGD sources.

However, since then, many of those PHP additions — mostly cherry picked from LibGD’s upstream — have made it into the official LibGD. The GD extension configuration, however, has not changed to reflect this.

To this day, if you compile the GD extension as a module, it will break half of the extension’s functions as punishment for dynamically linking. The GD extension does not even link to XPM, and no combination which can be installed to give you a GD extension with support for XPM.

Looking through the GD extension source code, there are hundreds of functioned #ifdef’ed out should you be dynamically linking to anything other than the pack-in LibGD — even when your LibGD supports it. The configure script does not even give you an option to use the pack-in LibGD when compiling it as a module.

Enter the problem — distributions do not statically link their software. It wastes disk space, and in the case of PHP’s pack-in LibGD, it is a security risk because the code has not been as reviewed and tested as that in the main. This means when Ubuntu, Debian and so on build their php5-gd package, it is coming with a ton of missing functions.

The only solution I found was to seriously hack up the code. I took out literally dozens of checks from the source code where it will be shocked back into omitting functions. It’s phenomenal that I had to manually remove dozens of checks — missing even one would result in a library linked to LibGD but with the functions still missing.

Better yet, every time you run the configure, new C files are generated to shut it all back off.

It took hours of work, but in the end, it proves what I long suspected: everyone on the Ubuntu forums and in ##php telling me that their PHP5, installed only from the apt-repositories, could support createfromxpm were full up to their eyes with shit.

Simply installing libgd2-xpm and libgd2-xpm-dev instead of the non-xpm equivalents will never, ever fix this problem.

I now have a PHP5 module which links externally to LibGD and supports all the XPM, XPM and Freetype functions. It is up in my repository and has been named to be an upgrade to the one in Ubuntu main.

It rather annoys me I will have to maintain such a plugin on my own. libPirate uses XPM calls for some of its functions, and that makes my build necessary.

Hopefully someone from the PHP group will update the configure scripts to actually check what users have installed and be more careful with what gets disabled.

Related posts brought to you by Yet Another Related Posts Plugin.