Front page | perl.macosx |
Postings from May 2003
Re: Bad Perl!
Thread Previous
|
Thread Next
From:
Sherm Pendley
Date:
May 10, 2003 20:57
Subject:
Re: Bad Perl!
Message ID:
9669E04A-8364-11D7-8877-0030656B202A@dot-app.org
On Saturday, May 10, 2003, at 01:50 PM, Michael Taylor wrote:
> Perl.org's source code and your package distribution of the perl 5.8.0
> package may cause problems with Mac OS X applications such as command
> line CPAN, Fink, among others.
> The solution for me
With all due respect, the best solution is pre-emptive: Delve into the
Perl documentation until you're thoroughly familiar with Perl's
directory layout and the effects of the PERL5LIB variable. Then, plan
your installation before entering a single shell command. Installing
Perl is *not* a simple task, and trying to proceed as if it is (or
should be) quite often results in problems such as you describe.
In a nutshell, the problem is this:
Fink installs its modules into /sw/lib/perl5, and adds that to Perl's
module search path by setting the PERL5LIB environment variable. The
modules installed there are primarily XS modules compiled against Perl
5.6, and they are not compatible with other versions of Perl. But, the
path specified in PERL5LIB is searched before any others, so any modules
installed there take precedence over modules installed in the standard
locations.
In other words, if you want to use 5.8, do *not* install any of the
pre-built modules available through Fink - they don't work with 5.8.
There is a similar problem with Apple's instructions:
Many people follow these instructions and choose to install 5.8 in
/Library/Perl, thinking that this will allow both 5.6 and 5.8 to
continue functioning properly - but that's not the case. Perl 5.6 is
installed in two places - core modules are installed in
/System/Library/Perl, while optional modules installed later are in
/Library/Perl. When you install 5.8 into /Library/Perl, these modules
are not deleted, so 5.8 will attempt to use them; if any of them are XS
modules, they won't work.
If you want to continue using 5.6 along with 5.8 - for regression
testing, for example - it gets worse. Any modules that were optional in
5.6, and thus installed in /Library/Perl, will be overwritten by their
5.8 counterparts. Because Apple's instructions result in a 5.8 that's
configured to install all modules, both core and optional, under
/Library/Perl, this includes not only modules that are optional in both
5.6 and 5.8, but those that were optional in 5.6 but have been moved
into the core 5.8 distribution.
To be fair, Apple's documentation does state that, at the time they were
first written and published, they were only tested on a "clean" system
with no optional modules installed. However, many people have attempted
to follow their instructions and encountered problems, and the issue has
been discussed here quite often. One would think that they'd update
their docs appropriately.
Also in the sake of fairness, the instructions are otherwise quite good,
and address a common localization problem found by many. The only
problem I've found with them is the suggested installation location - I
recommend using /opt, /opt/local, or some other out-of-the-way location
instead of either /usr or /usr/local.
> I installed Fink on the first drive and installed the latest version of
> Storable.pm-2.07.
When you installed the newer Storable, did you make use of the UNINST
option? The issue of replacing a core module - i.e. one that's included
with Perl - with a newer version of the same module from CPAN is well
documented, and using "make install UNINST=1" is the traditional means
of doing so. It causes the 'make install' step to delete the older
version from the core modules directory while installing the newer
version in the optional modules directory.
> I used Path Finder from www.cocoatech.com to track down the older
> Storable.pm perl modules:
Please don't take this the wrong way, as I don't mean it to be demeaning
or insulting. The fact that you need a GUI app to find a file, rather
than simply using the standard 'locate' command-line tool, shows that
you are probably relatively inexperienced with the UNIX environment.
There is also the fact that Perl is not likely to have been the primary
focus of a medical education.
With that being the case, I think you should reconsider your assertion
that the Perl distributions you've tried to use are badly configured.
You should consider instead the possibility that you were inadequately
prepared for the task you attempted, and because of that made mistakes.
This is not, by any stretch, a Bad Thing - unlike in medicine, mistakes
here are generally non-fatal. I have no idea how many Perl installations
I've botched over the years before I learned to get it right. Making
mistakes and correcting them is a necessary part of the learning process.
sherm--
"I have no special gift, I am only passionately curious." - Albert
Einstein
Thread Previous
|
Thread Next
-
Bad Perl!
by Michael Taylor
-
Re: Bad Perl!
by Sherm Pendley