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

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

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.

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

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

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!

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.

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.

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?

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>.

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