A Mess with Different Perl Installs

A mess with different Perl installs

You should:

1. cleanup

   • clean (comment out) your ~/.profile from any unwanted paths, and so on
   • clean any new perl installation from your $HOME (move to safe place for sure)
   • in short, try return your environment into previous working state

2. relog, (logout, login)

3. repair your system perl. Thats mean,

   • read @Sam Varshavchik's answer
   • reinstall it from your distribution, using your package manager (5.10).
   • this step should overwrite the mess you caused.
   • test it !
   • don't continue until youre ensured, everything working right as before.

Lesson learned: never overwrite your system perl

4. learning

   • read thru perlbrew.pl
   • repeat previous step once again, especially with the
   • the homepage
   • http://perlbrew.pl/Perlbrew-and-Friends.html
   • https://metacpan.org/pod/App::perlbrew
   • https://metacpan.org/pod/perlbrew

5. installing perlbrew

   • run the installation command \wget -O - http://install.perlbrew.pl | bash
   • should finished without errors
   • follow the instructions how to modify your startup file e.g. ~/.profile or such... (you need to add one line to the end)
   • check your ~/perl5/perlbrew/bin should contain prelbrew and patchperl

6. relog

7. setup new perl, run

   • perlbrew init #init environment
   • perlbrew available #show what perl you can install
   • perlbrew install 5.20.0 #will take few minutes - depends on your system speed
   • perlbrew install-cpanm
   • perlbrew list #check
   • perlbrew switch perl-5.20.0 #activate newly installed perl 5.20

Check your installation

• in the ~/perl5/perlbrew/bin you should have 3 scripts: prelbrew , patchperl , cpanm
• perl -v should return 5.20
• type cpanm - should return ~/perl5/perlbrew/bin/cpanm

You're done.

8. CPAN modules

You can install new modules with cpanm, like:

• applications

• cpanm cpan-outdated
• cpanm App::Ack
• cpanm Unicode::Tussle
• cpanm Perl::Tidy
• cpanm Perl::Critic

• collections

• cpanm Task::Moose
• cpanm Task::Plack
• cpanm Task::Unicode

• modules

• cpanm Path::Tiny
• cpanm Try::Tiny
• cpanm JSON
• cpanm YAML
• etc...

Check the ~/perl5/perlbrew/perls/perl-5.20.0/bin/ for new commands

You will need update your own perl script's shebang line to

#!/usr/bin/env perl

I hope don't forget anything, maybe other more experienced perl-gurus will add/edit/correct more.

Anyway, in the reality the steps 5,6,7 are much easier as sounds (by reading this) and could be done in few minutes.

Can I re-use modules compiled with a different build of Perl, but with the same version number?

It turns out that, YES, you can re-use modules compiled with different builds of Perl that have the same version number. The trick, as stated above, is to build your localperl with the ./Configure flags as close as possible to your system Perl. You can determine the ./Configure flags your system Perl uses by running perl -V. You should then use those settings with the flags listed above. My intuition is that -Dcc= and -Darchname= are the critical ones to match, though I have not had time to test this assumption.

So, what was my problem if I had already done all of this, and it still wasn't working? Simple - the test script! In my shebang line, I was still pointing to a faulty build of Perl that I had compiled earlier that day! D'oh! Once I pointed the script to the new build with all of the extra ./Configure options, it worked perfectly fine and was able to use all of the modules built with system Perl.

What concerns should I have when installing additional Perl modules on a server?

I do not know your company's policy, but it would probably be a better idea not to mess with your system perl and install the additional libraries and their prerequisites (and even a dedicated perl) in a different location and use lib.

See also How do I keep my own module/library directory? in perlfaq.

Do different versions of Perl require different CPAN module installations?

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.

What is difference between installing a perl module and copying whole folder?

A few off the top of my head:

• In case of an XS module, the code is compiled for the local platform.
• Installing a module via cpan usually runs the test suite so if there is any other reason beyond dependencies why it wouldn't work, you're told so (I guess that's very rare though)
• Regular installation automatically goes to a directory where your perl can find modules.

Of course you can take care of all these yourself. These days chances are pretty good you're running either Linux or Windows on something x86-ish and as long as you only copy Linux to Linux and Windows to Windows, and to the same place as on the source system, you'll be fine. Basically that's what binary Linux distributions and ActivePerl packages do, too, and it may make sense e.g. if you want to avoid installing a whole bunch of compile-time dependencies on all target systems. Just make sure you don't get yourself into a mess by writing to system directories (e.g. /usr/share/perl5) that are supposed to be managed by your system's package manager.

Is it possible with Padre to run and debug Perl scripts with a different Perl version?

Under Tools->Preferences->Language - Perl 5 you can specify the perl binary as well as its parameters to run your projects.

---

Related Topics