Common problems with LEDA installations Common problems with LEDA installationsPerl looks for modules in a series of library directories listed in the @INC global array -- typically /usr/lib/perl5/site_perl/5.6.0, /usr/lib/perl5/5.6.0, or similar paths based on the perl version number. The contents of this variable are determined when the Perl installation is built/installed (though,as a programmer, you can subsequently add more places for perl to look through the use of 'use lib' statements and the like). There are a number of ways in which @INC's contents can get out of step with reality. To make things even more interesting, the mod_perl module used by Apache has its own @INC, again determined when the module is built, and different from the one used by the perl binary on your server.
Usually things get messed up when you're installing CPAN modules. Some of these insist on having a newer version of perl than the one distributed with RedHat 7.X, and force an installation of the newer version (at this writing, usually 5.6.1 instead of the preinstalled 5.6.0). Unless you're careful (see the section below), the new installation of perl will be built with an @INC that includes only the libraries from your new version of perl -- and, just to make things more interesting, you'll end up with a lot of stuff installed where mod_perl can't find it, because the @INC mod_perl knows about is aimed at the older version.
This is, to say the least, confusing, and you're probably not going to get out of it easily, I'm sorry to say. If you're lucky, and you catch the problem before the new perl is completely installed, you can probably save yourself some work, as follows:
The perl configuration script gives you a number of opportunities to tell the new version that an old one exists. Unfortunately, the configuration questions are worded in a way that doesn't make this all that obvious, and they're far apart in the configuration. Read through all the information below; the questions will not necessarily be presented to you by the configuration script in the same order that they appear here.
The first and most important thing is to make sure that perl gets installed with a directory prefix that is the same as the earlier version. Otherwise things will be even more hopelessly confused. To find out where the old perl is, open another session and say
which perl
This should cough up the path to the currently installed perl -- usually (under RedHat) /usr/bin/perl. This is not the default that the perl configuration script will present -- be careful. The script will say something like
By default, perl will be installed in /usr/local/bin, manual pages under /usr/local/man, etc..., i.e. with /usr/local as prefix for all installation directories. Typically this is something like /usr/local. If you wish to have binaries under /usr/bin but other parts of the installation under /usr/local, that's ok: you will be prompted separately for each of the installation directories, the prefix being only used to set the defaults.
Installation prefix to use?
For RedHat, you'll most likely want to make the prefix /usr/bin, then accept the defaults from there on out.
At some point you'll see something like
In order to ease the process of upgrading, this version of perl can be configured to use modules built and installed with earlier versions of perl that were installed under /usr/local. Specify here the list of earlier versions that this version of perl should check. If Configure detected no earlier versions of perl installed under /usr/local, then the list will be empty. Answer 'none' to tell perl to not search earlier versions. The default should almost always be sensible, so if you're not sure, just accept the default.
Note that the default may not, in fact, be sensible, particularly if you've managed to install your perl under a different tree than the earlier version. Give it a list that includes the older versions you have installed.
Another relevant question is
Enter a colon-separated set of extra paths to include in perl's @INC search path, or enter 'none' for no extra paths.
Respond to this with a list of paths in which the old perl modules are contained. One way to find out where they are is to open another console session (either a new xterm window, or by hitting Alt-F2 or some such if you're using a nongraphical console) and saying
find /usr -name "*.pm" -print
This will show you where all the Perl module libraries are.
Probably the best bet is to simply install a new mod_perl that uses the newer perl version you unintentionally installed, and reinstall all the CPAN modules you need for LEDA. You can do this in any order -- either CPAN first or perl first. Before you do so, say perl -V to get a look at what's in @INC; it should be pointing to the libraries for the newest version you have just (inadvertently) installed -- you'll know because the version number will be some component of most of the pathnames in @INC.
If you've just installed 5.6.1 (usually the case as of the time of this writing), you'll need to get the source code for mod_perl 1.26 or later. You can download source code from http://perl.apache.org/dist/ , or from CPAN. You will want to read the INSTALL documents that come with the distribution. Assuming you've got a standard RedHat setup, by far the easiest method of reinstalling mod_perl is to use the APXS method to build the module on its own and install it into the Apache layout. I usually use a little shell script to do this, since it then hangs around as a reminder of what I did. Mine looks like this:
#!/bin/sh
# Tom's little helper for building modperl
perl Makefile.PL \
USE_APXS=1 \
WITH_APXS=/usr/sbin/apxs \
PERL_USELARGEFILES=0 \
EVERYTHING=1
You might want to confirm that the APXS program is at /usr/sbin/apxs -- usually it is, but sometimes not. Say
which apxs
to be sure. Note that you may or may not want the PERL_USELARGEFILES line, depending on how your Apache server was built. The Makefile.PL script will complain if this is inconsistent, so keep an eye out and set the parameter accordingly. Once the configuration is run, say
make ; make install
to build the new module. After a successful build, restart your Apache server. Try to look at http://www.yourserver.dom/server-info to see if you've in fact got a running mod_perl. If you have trouble with the Apache server returning no data and leaving messages about segmentation faults in your Apache error log, see the section on "Mod_perl badly built" below.
In versions of Apache earlier than 1.3.20, this problem often resulted from conflicts in use of the expat XML parsing library by Apache, PHP, and mod_perl. It is easier to upgrade to the newest versions of these software packages than it is to repair the problem in older versions, so do the upgrades.
If you're seeing this problem with later versions, it's probably because your mod_perl is set up with PERL_USELARGEFILES=1 and your Apache installation isn't. This is even more likely to be the case if you've just reinstalled mod_perl from source because you need a perl 5.6.1 mod_perl. If so, rebuild mod_perl with PERL_USELARGEFILES=0 (see the shell script in the section above).