Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Wow! Painful upgrade to Perl 5.12

by ack (Deacon)
on May 18, 2010 at 17:13 UTC ( #840550=perlmeditation: print w/ replies, xml ) Need Help??

A few days ago I decided to "bite the bullet" and upgrade from my workhorse Perl 5.8 to 5.10. I discovered that ActiveState had v5.12 and I thought...Wow!...bonus!

I have upgraded through three major release upgrades of Perl over the past several years and it has been painless and straightforward. I had resisted this upgrade due to an erronious understanding of my IDE which I thought had hard-wired itself to specific versions of Perl. But doing some research and thinking about it logically (I'm not known for that kind of "good practie") I realized that the IDE doesn't care what version of Perl, it only cares about where to look and what the executable's name is.

So, excited by a lot of what I'd heard and read about the newer versions of Perl I did the upgrade. It was as painless as deleting the old version and installing the new one and my IDE just keeps on cranking along.

I thought "Wow! This is terrific! Wish I had done this earlier."

Then all the world began to crumble. I discovered, after reading the upgrade Readme file that I would have to reload all my CPAN modules...all 547 of them! So I spent almost 3 days grinding my way through THAT process. At the conclusion I thought "OK, I only had a few CPAN modules in the past so I guess that's a bit of the price I have to pay for becoming a more prolific CPAN user (but I've come to love my CPAN modules!)." Seems like there should be a more automated way to do it. But I didn't have the energy or will to build my own automated approach in Perl so I just chalked it up to fate and was grateful I had gotten it done...even it was manually.

Then more and more of my scripts began failing. I thought "What's going on?" I did a bit more researching and discovered that many of the CPAN modules can't work with 5.10 or later! Apparently, in particular, it is true for many of MY scripts!

I keep getting error messages of (I paraphrase) "Can't find Perl59.dll..." which is an indication that a module (as far as my research tells me) needs the old Perl 5.8. At first I thought it was because I had some how missed re-intalling the particluar modules. The error messages didn't tell me which modules, so I just presumed that it is at least one of the modules in that script's use invocations. So I just re-did the re-installs for all of that cript's modules.

That did, indeed, at first seem to remedy the problem.

But then more and more of my scripts kept failing even afeter I did the module re-install. And I have yet to get them to work.

So, long story short, I am completely disenchanted with the upgrade and am about to get rid of it and go back to 5.8.

I do almost all of my module installations using ActiveState's Perl Package Manager (PPM) on my Widnows XP system because it is genearlly the simplest and easiest approach. I occasionally have used the CPAN installer and have even less frequently done the installs mannually using nmake.

I'm not looking for any advice; but I am really frustrated as I was looking forward to exploring some of the really neat features of the newest versions. I'm disappointed that apparently that is just not going to be possible.

ack Albuquerque, NM

Comment on Wow! Painful upgrade to Perl 5.12
Re: Wow! Painful upgrade to Perl 5.12 - Test before release
by moritz (Cardinal) on May 18, 2010 at 17:35 UTC

    I can feel with you - it's much work to upgrade the modules, or to do fresh installs with the new Perl version.

    To avoid that pain in future (both for you and others), I'd like to encourage you to test release candidates of stable perl versions before the final one hits the CPAN, and report any bugs you find, and any trouble you have with the new perl versions.

    Only with feedback from users can the perl developers release stable, mature and backwards compatible versions of perl. Don't think somebody else does that already - there are people, but they have different configurations and different code bases. So your feedback counts.

    Also things that nobody tests might go away - as happened to suidperl.

    Perl 6 - links to (nearly) everything that is Perl 6.

      Thanks, moritz. I will do my best. Having never had this challenge before, I think I was just too shell-shocked to realize what was going on. I have spent the last several days 'recovering' and now have largely succeeded...and I have to say that I do very much like Perl 5.12! I still get a few modulesm that are a bit persnickety...not sure why. But chromatic's response below yours is the real root of the problem, I believe, and I am busy trying to shore up my blunder. Thanks to eveyone's great responses. PerlMonks are the greatest!

      ack Albuquerque, NM
Re: Wow! Painful upgrade to Perl 5.12
by chromatic (Archbishop) on May 18, 2010 at 17:43 UTC
    I keep getting error messages of (I paraphrase) "Can't find Perl59.dll..."

    That suggests that you didn't delete all of your previous installation, in particular the directories for additional modules and their compiled XS components, and that you installed the new version of AS Perl into the same directory as the previous version.

    The solution has two parts. First, use the uninstaller (if it exists; I use neither AS Perl nor Windows). Second, consider installing each new version of AS Perl into a unique directory.

      chromatic, you've hit the nail on the head, as they say! In the past I have always installed each new generation of Perl into its own directory and I have used the AS Perl uninstaller to get rid of the old Perl version.

      I didn't do that this time for two reasons: (1) I could not find the uninstaller...my fault as I think I inadvertantly deleted it some time ago... and (2) in the past I remembered that I had some problems getting my IDE to point to the correct location for Perl when it got put in another directory. The latter was the primary motivation to use the same old directory and that part worked perfectly...my IDE just went merrily along.

      But then, of course, as you so aptly point out, the problems just began to multipy.

      In the past, the AS uninstaller did the job of 'cleaning up' all the little nasties that are the primary source of my current woes...most noteably the missing old .dll. So I will haved to go in and finish the clean up by hand...guess that'll teach me. I wish I had the uninstaller.

      Again, thanks chromatic.

      ack Albuquerque, NM
Re: Wow! Painful upgrade to Perl 5.12
by ikegami (Pope) on May 18, 2010 at 18:43 UTC

    You may think of Perl as a language or as a executable, but it's also a library. This allows C code and Perl code to be interfaced.

    The source interface to the library is backwards compatible, which means an XS module that can be compiled using Perl 5.8 should have no problem being compiled with Perl 5.10.

    The binary interface to the library is backwards compatible between minor versions, which means an XS module that was compiled using Perl 5.8.8 doesn't need to be recompiled if you upgrade to Perl 5.8.9.

    The binary interface to the library is NOT backwards compatible between major versions, which means an XS module that was compiled using Perl 5.8.x DOES need to be recompiled if you upgrade to Perl 5.10.x.

    That's why you need to reinstall your modules. If you don't, if you use a module compiled using Perl 5.8 with Perl 5.10, you get "Can't find Perl58.dll".

      Thanks ikegami. I sort of intuited something like that...but never knew for sure.

      I wish I had a way to automate that re-install with all the CPAN modules I've got. I don't do the changes quite often enough to motivate me to build my own tool...but maybe I'll give it some thought. I'm sure I'll face this chalenge again.

      ack Albuquerque, NM
Re: Wow! Painful upgrade to Perl 5.12
by BrowserUk (Pope) on May 18, 2010 at 21:35 UTC

    If you're using activestate and ppm, in theory, ppm upgrade --install will upgrade all your PPMs after you've upgraded your installation.

    And (again, in theory), if you used the cpan shell for some or all of your installed packages, cpan> upgrade will deal with them.

    I tried it once and it didn't get everything. But I also tend to install some modules with the four-part matra, so perhaps it was my fault.

      BrowserUk, that's wonderful! Thanks. I'll go investigate and give it a whirl. I would be delighted if it even works for 'most' of my modules. I didn't know about that option on ppm.

      I have also used the CPAN shell on occasion (but I don't use it very often so I always have to re-learn it which is sort of a pain) so I'll keep the cpan> upgrade in mind, too.

      Again, thanks.

      ack Albuquerque, NM
Re: Wow! Painful upgrade to Perl 5.12
by JavaFan (Canon) on May 18, 2010 at 22:45 UTC
    Then all the world began to crumble. I discovered, after reading the upgrade Readme file that I would have to reload all my CPAN modules...all 547 of them!
    Really? That's not necessary for plain perl. There you only need to recompile those modules that depend on the architecture (which typically means XS modules). No need to recompile (or reinstall) pure Perl modules.

      I have installed Perl 5.10 via FreeBSD Ports & modules that I use (system wide). Few days ago I also installed Perl 5.12 RC2 in my own user directory. After installing a module (and optional dependecies) not availble yet via FreeBSD ports with perl 5.12, I was thinking of installing pure perl modules in a tree separate from the ones which need to be compiled.

      Point would be to share pure perl modules as much as possible, and avoid duplicate or reinstall among various perl versions as far as possible. My query in that regard is is there a way to distinguish a module (between a pure perl or compiled one) via cpan(plus) or during "perl (MakeFile|Build).pl .. (make|Build) install"?

      Having different trees might not work out too well while automatically installing witin cpan(plus) as the initial tree might be set to the appropriate type based on the primary module, but not for subsequent dependencies. Seems like, cpan itself would need to be changed to accommodate the scenario.

      If there are other suggestions to have separate version independent trees (of pure perl modules in one, compiled, version specific in another), I am all ears.

        Modules that aren't part of the core system are (unless overridden) installed in $LIBDIR/site_perl/<perl-version>/. Vendor (Linux distros for instances) supplied modules ought to go into $LIBDIR/vendor/<perl-version>. Core modules go into $LIBDIR/<perl-version>.
        Point would be to share pure perl modules as much as possible, and avoid duplicate or reinstall among various perl versions as far as possible.

        How do you know those pure Perl modules have no XS dependencies, and how do you know those pure Perl modules and their dependencies work unmodified on newer versions of Perl 5?

        I was thinking of installing pure perl modules in a tree separate from the ones which need to be compiled.

        You can instruct Perl's builder to add the lib directories of other Perl installations to the list from which @INC is initialised. Pure Perl modules will work fine, XS modules will give an error.

      Indeed, you're right on target. The modules that I've had trouble with, as ikegami pointed out, are those that are not 'pure Perl'. I have quite a few non-pure-Perl modules.

      Thanks, JavaFan. I really appreciate the response.

      ack Albuquerque, NM

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://840550]
Approved by Corion
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2014-12-18 03:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (41 votes), past polls