Better use gcc or SUNs cc to compile it? Or better take some binaries for sparc, are there...??
As Corion points out, don't mess with your production server right away. Bad Things® can happen
if you do if there's an application out there that you don't know about that uses the Perl version that is
out there already and if there are custom modules that have been loaded either from the vendor or CPAN.
So before you start pushing bits around, do some homework. Talk to your application support people and
quantify the problem set before you go any further. Find out if and for what are they using the Perl sever
for in their production environment. Your application support folks might not be Perl savvy enough to know
what modules are being used or where they came from so be prepared to look at that stuff and figure it out
for them. Make a list. Check it twice. You want to be nice not naughty! (Sorry.. couldn't resist...)
Once you have quantified what you are up against, then you want to do some more homework. If the
applications and scripts in question come from an outside vendor then you have to take another step.
Talk to the
vendor and find out what you can from them. I'll warn you though, I've dealt with a couple of vendors
that shipped Perl scripts with their end product that another party wrote (probably a contractor) and
that party is not around to ask questions of. The company's own support staff definitely did not have
their clue bit set with respect to the inner workings of the script. ("The script stopped working...
what did you do to change it?" -- typical vendor)
If you are luckier that I was and somone at the software vendor has their clue bit set with respect
to the scripts then you can find out things like "Oh... our module Foo::Frag::Fuzz is actually not
compatible with version 5.x of Perl but is compatible with 5.y" or better yet "Oh.. if you are going to
upgrade the Perl interpreter then you need to update our modules to version Z." (I've had that happen
exactly once.)
Once you are armed with all that information, then you want to do your upgrades on a development, test
or QA system and test the living daylights out of what you've done. Keep good records of what you are
doing so problems that may come up are easier to trace.
Now, I've gotten way off my original track, but as far as SUN's cc or gcc goes the official answer
is "It depends!" All but one of the companies I've worked at in the last 25 or so years has shied away
from buying Sun's native compiler. (Actually at one time Sun's cc came with the OS "free" but that
was a long time ago) If that's the environment you are in and you are stuck with "free" software to
get your job done that limits your options. You can either compile from source or go visit sunfreeware.com
and get the binaries from there.
Just a side note. I've had a much easier time compiling from source on Solaris 8 and 9 than I've
had on Solaris 10. But that's for another discussion.
Once you've done your testing with the new Perl then you should work with your application support
folks and figure out a plan for deployment. In my environment we have all our production servers "mirrored"
in that there are at least two production severs for each functionality. So when we deploy something new
out to production that can have a wide impact we deploy it to one server, wait a couple of days to let it
soak in, and then to the other (or rest of the) server(s).
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
|