Installing Perl 5.8 on Jaguar


	Log In \| Not a Member?	Contact ADC

Editor's Note: This article was originally written after the release of Mac OS X 10.2 Jaguar, but the information is still relevant even with the release of Panther. Perl 5.8 is included in the installation of Mac OS X v10.3 Panther, but you may want to install your own version if you plan to customize it; or if you are still running Jaguar.

The newest release of Apple’s operating system, OS X v10.2 (Jaguar) is filled with many welcome improvements and additions. The integrated Address Book, improved Mail, System Preference tweaks—all good things. But what really excited me was the new stuff under the hood: bash, Python, gcc 3, Ruby. About the same time Jaguar was in development, work was finishing up on my beloved Perl, version 5.8.1.

A quick trip to Jaguar’s Terminal showed me that this version didn’t make it into the default install:

[cpu:~] user% perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level

As is almost always the case with UNIX-based systems, there is a workaround. So, if you’re looking to get Perl 5.8 up and running on Jaguar, I’m here to tell you how.

Preparation

If you’ve installed shell applications before, you know how the process usually goes: download the source, configure the source, compile the source, and install the source. Perl is no different, but does require some patience; compiling the package could take you an hour or more, depending on the speed of your machine.

Some caveats to consider before starting:

You need to have Apple’s Development Tools installed. To learn more about these and how to download the latest set for free, visit the Development Tools page on ADC.
If you use Apache’s mod_perl, you’ll need to recompile it.
The process described below was performed on a fresh install of Mac OS X v10.2, along with the Developer Tools. These instructions may not work perfectly on previous versions of Mac OS X.
If, after the installation, you get warnings about missing symbols, you probably have an old version of Perl (or parts of one) in /Library/Perl. These undefined symbols existed in pre-5.8.1 versions. For more information on this issue, check out perldelta.
OS X users that have installed Fink may experience various symbol errors when executing certain Perl operations. More on this can be found in the macosx@perl.org archives.
The Perl install docs state: “[Perl 5.8.1] is not binary compatible with releases of Perl prior to 5.8.1. If you have built extensions (i.e., modules that include C code) using an earlier version of Perl, you will need to rebuild and reinstall those extensions. Pure Perl modules without XS or C code should continue to work fine without reinstallation.” This means that after installation, some of your modules (like HTML::Parser, XML::Parser, etc.) may not work “out of the box” without re-compilation.

Downloading Perl 5.8.1

The first step is to download Perl 5.8.1 itself. You can find it on any number of CPAN mirrors worldwide. I opened up the Terminal and entered the following commands (you can replace the URL below with one that reflects your closest mirror):

[cpu:~] user% cd /usr/local/

[cpu:~] user% sudo mkdir src
[cpu:~] user% sudo chown root:staff src
[cpu:~] user% sudo chmod 775 src
[cpu:~] user% cd src
[cpu:~] user% curl -O ftp://ftp.cpan.org/pub/CPAN/src/perl-5.8.1.tar.gz
[cpu:~] user% tar zxvf perl-5.8.1.tar.gz
[cpu:~] user% cd perl-5.8.1

These instructions created a /usr/local/src directory with adequate permissions to move around. The curl -O command downloaded a copy of Perl 5.8.1 (about a 10 MB file) into this directory. Next, I extracted the archive into a directory called perl-5.8.1, and then moved into it.

Backing Up

Since Perl is already installed in OS X (and perhaps already tweaked and configured to your liking), you may want to think about backing up your existing installation. Perl is predominantly located in three places: the private system library in /System/Library/Perl, the local libraries in /Library/Perl, and the binaries (like perl, pod2html, h2xs, etc.) under /usr/bin. Depending on your needs, you may also have modules installed under /Network/Library/Perl. If you’re worried about things going wrong, you may want to save copies of these directories.

The Install Directory

Most shell applications offer you the choice of where to install, and Perl is no different. Some users install large applications in a directory called /opt, others follow Fink’s behavior and drop them into /sw, and still others follow the standard /usr/local. I’ll be using the default Perl layout for OS X which is determined by hints/darwin.sh. This file is included as part of the Perl distribution and is utilized during our initial configuration. Opening that file in a text editor, we’ll see that a default install is defined as:

# Default install; use non-system directories
prefix='/usr/local'; # Built-in perl uses /usr
siteprefix='/usr/local';
vendorprefix='/usr/local';
usevendorprefix='define';

# Where to put modules.
privlib='/Library/Perl'; # Built-in perl uses /System/Library/Perl
sitelib='/Library/Perl';
vendorlib='/Network/Library/Perl';

If we don’t specifically tell Perl to be installed elsewhere, the binaries will be installed into /usr/local/bin, and our Perl modules (our @INC) will be set for /Library/Perl. This means that Apple’s system library, /System/Library/Perl, won’t be utilized (and, if you were fickle enough, could be deleted). If you want the Perl modules installed in the exact same locations as Apple’s current Perl 5.6.0, then you’ll want to assign an install prefix of /usr, which hints/darwin.sh associates with the following directories:

# I'm building/replacing the built-in perl
siteprefix='/usr/local';
vendorprefix='/usr/local';
usevendorprefix='define';

# Where to put modules.
privlib='/System/Library/Perl';
sitelib='/Library/Perl';
vendorlib='/Network/Library/Perl';

Installation

When installing, it’s always a good idea to make sure you’re starting from a fresh build directory. This ensures that there’s no old configuration data or libraries hanging around and messing up your installation. Here’s the command (and don’t worry if this is your first time messing around with Perl—this command won’t hurt anything):

rm -f config.sh Policy.sh

If you want to experiment with different Configure options, then be sure to run the following to start afresh (this command duplicates the above deletion, along with cleaning out stuff created during a Configure):

make distclean

Configure and Options

Now comes the first part of your great journey with Perl 5.8.1: the configuration. Perl needs to know hundreds of bits of information to be correctly compiled for your architecture. Thankfully, the Configure script handles most of this for you. Before moving on, however, you need to set an environment variable:

setenv LC_ALL C
echo "setenv LC_ALL C" >> ~/.tcshrc

If you’re curious about what those commands are doing, then you’ll want to check the INSTALL file, as well as man perllocale. OS X has one of the necessary environment variables set (LANG), but without the above, you’ll get annoying error messages each time you try to run a script. The above assumes the tcsh shell; if you prefer bash, use echo “export LC_ALL=C” >> ~/.bash_profile instead.

Now, enter one of the following commands, depending on where you want Perl installed:

# you want to use the default Perl directories:
./Configure -de -Dperladmin=email@addr.com -Dcf_email=email@addr.com

# you want to install Perl the same way Apple did:
./Configure -de -Dprefix=/usr -Dperladmin=email@addr.com -Dcf_email=email@addr.com

The only difference between these two lines is the -Dprefix flag, which determines where Perl should be installed (the rest of this article assumes you ran the first one). The -de helps the configuration go more quickly by assuming the defaults for most of the questions, as well as not prompting you for further configuration of the generated config.sh. The -Dcf_email and -Dperladmin flags set the email addresses for the installer and administrator of this Perl installation, respectively. These flags are optional, as the Configure will automatically do its best to guess them.

You may also want to look at -Dotherlibdirs. With this option included in the Configure statement, you can add more library directories to Perl’s @INC. For example, if I wanted each of my users to have their own Perl library, I could use -Dotherlibdirs=~/Library/Perl. If I log in as morbus, I’ll be able to stick my own modules in /Users/morbus/Library/Perl without interfering with the rest of my Perl installation. Of course, if I didn’t use -Dotherlibdirs, I’d be able to duplicate the same effect in my code with use lib.

Compiling, Testing and Installing

Thankfully, the Configure command is the most brain-consuming part of the installation. Once the Configure is run (it took two minutes on my dual 400mhz G4), you’ll be home free. It will usually finish by saying, “You must run ‘make,’” so go ahead and follow its orders:

[cpu:~] user% make

This command took about 15 minutes on my machine. It should complete with the following: “Everything is up to date. Type ‘make test’ to run test suite.” Again, the install knows best, so run:

[cpu:~] user% make test

The testing process is a common part of a Perl-related installation. You’ll see a large number of tests run, most returning a status of “OK,” and some skipped due to our platform. You should only get two failures, both related to Berkeley DB:

ext/DB_File/t/db-btree...............#
# This test is known to crash in Mac OS X versions 10.1.5 (or earlier)
# because of the buggy Berkeley DB version included with the OS.
#
FAILED at test 0

This test, as well as db-recno, fails because OS X ships with an old version of a common database library (Berkeley DB, version 1.x). Perl gives us more advice concerning these failures:

# You can safely ignore the errors if you're never going to use the
# broken functionality (recno databases with a modified bval). 
# Otherwise you'll have to upgrade your DB library.

I won’t be showing you how to upgrade your Berkeley DB library, but bug reports concerning this have been filed both at OpenDarwin.org and Apple (#2923078 and #3021743). The make test took about ten minutes on my G4 and finished by saying: “Failed 2 test scripts out of 657, 99.70% okay.”

And now, the final step:

[cpu:~] user% sudo make install

If you ran the first Configure command above, you’ll see a progression of files installing into /Library/Perl (the Perl modules), /usr/local/bin (the Perl binaries) and /usr/local/share/man/ (Perl-related documentation). This should finish in less than five minutes.

Testing Your Installation with CPAN

Now that you’ve installed the new Perl, it’s easy enough to make sure it worked with perl -v (you can also check the configuration with perl -V). But a stronger, more certifiable way to test it is by running one of the more common Perl programs: CPAN, the Comprehensive Perl Archive Network. As its name suggests, CPAN is a huge repository of Perl code, and also the primary means of installing and updating Perl modules.

Modules have been written for every conceivable purpose, from interfacing with database applications to rendering graphics to parsing various types of specialized files. Fresh installations of Perl come with a number already installed; you can find them by browsing through the /Library/Perl directory. But if none of the included modules meet your needs, then CPAN is your next step.

Installing a new Perl module by hand, while not extraordinarily difficult, can be a bit of a hassle. It involves downloading and unpacking the module, configuring it, and building it, all the while making sure there are no unresolved dependencies or conflicts between modules. If you’re the sort of person who enjoys that kind of process, go right ahead. There is an easier way to go, however.

CPAN.pm is a Perl module whose purpose is to automate the downloading and building of modules. It takes care of the tricky situations where certain modules require other modules to run, and those modules in turn require additional modules, and so forth. It also supports the building and installation of bundles, which are groups of related modules that work together to handle a particular set of functions.

To start CPAN, enter the following:

[cpu:~] user% sudo perl -MCPAN -eshell

If this is the first time you’re running the module, you’ll be asked a series of questions about how your system is set up. In most instances, the default answers will work, but make sure that the network setup questions are answered correctly so that CPAN.pm can get online and properly fetch new modules. The answers you give will be saved in ~/.cpan/CPAN/MyConfig.pm. If your setup changes, or you think you answered a prompt incorrectly, you can change your settings by opening that file with a text editor and modifying the appropriate lines.

Eventually, you’ll see something like this:

cpan shell -- CPAN exploration and modules installation (v1.61)
ReadLine support available (try 'install Bundle::CPAN')

cpan>

Go ahead and install this Bundle::CPAN thing. Perl modules that are closely related to each other (like all Digest modules, all Net modules, etc.) are packaged into “bundles,” creating quick combined installs. To install Bundle::CPAN, just use this command:

cpan> install Bundle::CPAN

Ultimately, that’s all you need to know about installing modules for your shiny new Perl (and any previous version of Perl, actually). We’ve both verified that our Perl 5.8.1 installation is working smoothly and improved our CPAN capabilities. As the above command executes, you’ll notice CPAN downloading, extracting, testing, and installing modules and their prerequisites.

Another useful CPAN command is simply r. Once run, CPAN will search through your Perl modules, comparing your installed versions with the latest versions available. When finished, it’ll show you a compiled list:

cpan> r
Package namespace     installed    latest  in CPAN file
Math::BigFloat             1.35      1.36  T/TE/TELS/math/Math-BigInt-1.61.tar.gz
Math::BigRat               0.07      0.08  T/TE/TELS/math/Math-BigRat-0.08.tar.gz
Pod::Text                   2.2      2.21  R/RR/RRA/podlators-1.24.tar.gz

To get up to date, it’s a simple matter of issuing install Math::BigFloat, install Math::BigRat, etc.

Another useful CPAN command is force, which will unconditionally execute a command, regardless of other results. If you recall the caveats at the beginning of the article, modules that have been built with XS or C code under 5.6.0 won’t work under 5.8.1, forcing you to recompile and reinstall. But what if you already have the latest version of, say, HTML::Parser? CPAN complains:

cpan> install HTML::Parser
HTML::Parser is up to date.

That’s where force comes in. Simply prepend it to any CPAN command and it’ll execute unconditionally (i.e., whether the module is already installed, tests fail, prerequisite libraries can’t be found, etc.):

cpan> force install HTML::Parser
Running install for module HTML::Parser
.
.
.

Web Applications

The most common use of Perl, and one of its strong points, is CGI: processing and outputting data for Web applications.

Before you can use Perl for CGI scripts, you need to start the Apache Web server. If you haven’t done so already, go into the Sharing pane under System Preferences and click the button to turn Web Sharing on. After a few seconds, Apache will start running in the background. You can type ps -ax in a Terminal window to display a list of running processes, and you should see /usr/sbin/httpd in the output. That’s Apache, also known as the HTTP daemon. With Web Sharing switched on, Apache should automatically start every time you boot up your Mac. Now, if you open a browser window and go to http://127.0.0.1/, you should see the default index page that Apache serves up when it’s freshly installed.

Apache looks in the /Library/WebServer/Documents directory for Web content to serve. Each user on your system also has his or her own area for Web content: the Sites directory in the user’s home directory. Users’ personal Web directories can be accessed in a browser by prefixing the user’s name with a tilde (~). So, for example, you can view the Web site of the user named morbus by going to http://127.0.0.1/~morbus/.

Perl (and other) CGI scripts reside in /Library/WebServer/CGI-Executables on a standard Mac OS X installation. Two CGI scripts should already be in this directory: test-cgi and printenv. test-cgi is a shell script that displays the values of various environment variables. printenv performs a similar function, but is written in Perl.

For the vast majority of Perl CGI applications, you’ll want to use the CGI.pm module which makes parsing form data and outputting HTML easy. Once your Perl application is written, place it in the CGI directory (/Library/WebServer/CGI-Executables), give it execute permissions (chmod 755 scriptname), and then access it via the Web (http://127.0.0.1/cgi-bin/scriptname). For more information on setting up and maintaining your Apache webserver, try this series at O’Reilly. Also worthwhile reading at the O’Reilly site is Build Your Own Apache Server with mod_perl.

Conclusion

At this point, your Perl 5.8.1 installation should be rock-solid, complete with updated modules and the knowledge necessary to rebuild 5.6.0 extensions. Future updates to the Perl 5.8 branch should follow this same installation procedure.