The slippery slope of open source

If you work with open source software, you’ve been to the place I’ll describe in this column more times than you care to count. It always starts innocently enough. In my case, I needed to re-create a Linux-based development environment on my Apple PowerBook. The essential ingredients were Apache, Berkeley DB, mod_python, and libxml2. Pretty standard stuff, but I’d never assembled all the pieces on Mac OS X.

If you don’t work with open source software, it’s hard to explain how weird this process of assembly can be. I’ve never actually run Autoconf, the GNU tool that’s used to generate the configuration scripts that probe every nook and cranny of your operating system, compiler, and libraries. But I’ve run lots of configuration scripts, and I fondly remember the cover of a 1988 issue of The Perl Journal. It depicted an Underwood typewriter, circa 1940, with this transcript rolling across the platen:

# sh ./Configure

Beginning of configuration questions for Perl 5.

Hmm … this looks like an Underwood portable.

AFS does not seem to be running…

Installation prefix to use? (/usr)

Warning: no “1” key detected. Using “l” instead.

Use which C compiler? (CC)

This perfectly captures the experience of building free software from source. It’s rarely so hopeless, but it often turns into a dizzying game of chutes and ladders -- especially on a Mac.

In this case, the slide down the slippery slope began when mod_python told me it preferred Apache 2 to the stock Apache 1.3 that Apple ships. That upgrade went smoothly, but I knew Apple’s stock Python 2.3.5 wasn’t the one I wanted mod_python to use. So I pointed its configure script at /opt/local, where I’d built a Python 2.4 with the libxml2 and Berkeley DB bindings I wanted. But when I fired up Apache, it reported a mod_python built with Python 2.3.5, not 2.4.

Yeah, I shoulda read the instructions. It’s been a while since I used mod_python, and although it used to let you point to any instance of Python, now it will use only the installed one.

Well, OK. I’d been meaning to upgrade to the newest production Python, 2.4.3, which was released last month. And lo, there’s even a binary installer for Mac Python. Joy! Except it doesn’t include the libxml2 bindings, and when I try to build them, the tool chain can’t cope with the universal binaries the installer gave me. Sorrow.

Well, OK. Binary installers are for wimps, anyway. Real men and women build from source. So I try, GCC spews forth alarming messages about “semwait” and “bad file descriptors.” Inevitably, I wind up Googling for these obscure error messages.

The first proposed workaround sounds plausible: Switch from GCC 4 to GCC 3. No dice. The second sounds unlikely: Download the source again and start over. But I do, and for no apparent reason, this time it works.

Now admittedly, most of the issues I ran into were Mac-related. Linux is home base for open source software, and things always go much more smoothly in that environment. I can almost understand how some folks throw away OS X and install Linux on Apple hardware -- almost, but not quite. Until Linux feels better than OS X on a laptop, I guess I’ll keep playing these games. … although I’ve got my eye on a nice-looking Underwood typewriter.