Do different versions of Perl require different CPAN module installations?

Question

We have a server farm that we are slowly migrating to a new version of Perl (5.12.1). We are currently running 5.8.5. The OS will be upgraded from RedHat 4 to RedHat 5 as well, but RedHat 5 is still back on Perl 5.8.8. Thus for a while in our source tree we'll be supporting two versions of Perl.

I have been told to install the new version of Perl into our source tree, and also all of the CPAN modules we currently use. I was actualy told to 'compile' the modules with the correct version of Perl. I'm confused by this. Do some modules actually configure themselves differently for different versions of Perl? Given this, I assume I should configure a CPAN directory for each version of Perl in our tree?

Any information or 'gotchas' about this scenario?

Edit: As an additional question, will the same cpan directory (pointed to by ~/.cpan) serve for both trees, or should I link in different directories when I'm working in different trees (installing modules)?

Answer 1

Some perl modules compile and link themselves to system libraries. If you upgrade your OS there is a chance that these libs are not present anymore which will cause these modules to misbehave or not run at all. Therefore recompiling your perl modules is recommended.

If you reinstall a new version of perl from scratch on your new system then you should face no problems, as during installation the right headers and libs will be used.

Answer 2

It will not be the version of Perl which is the issue but the underlying platform. Redhat4 and Redhat5 are much more different than Perl 5.8.5 and 5.8.8. In fact if you find a difference between these versions, it is probably a bug.

RH4 and RH5 have different library sets, and the perl native extensions will have to be recompiled against these libraries. If you keep these compiled trees in your source repository, you will indeed need 2 trees. If you want to avoid this you could 'statically compile' but this gets extremely messy and might severely impact the memory footprint and associated load times of the script, not recommended (and in many cases not even possible).

A cleaner solution would be an install script which downloads/compiles/installs copies from the CPAN and keep the source tree free of these artefacts. You can still decide if you want to do this as part of installation on the target machine or as part of building a binary package before installation on the target machine.

Answer 3

Any perl modules that use XS (compiled C code, dynamically loaded) will, in general, only work with the same version of perl that they were compiled with. This is for two reasons:

Reason one is that by default they're installed into a directory that includes the perl version number, and any other version of perl won't look into that directory.

Reason two is because the perl API can change between major versions, so even if you were to copy the libraries into the appropriate directory, they might or might not work depending on what features they use, and how different the two versions of perl are. Between 5.8 and 5.12 there are significant differences that are likely to break nearly all code.

This doesn't apply at all to pure Perl modules, though; they can be copied around freely with very few exceptions. It's only XS code that's the issue.