The module you are trying to load was installed by a different build of Perl than the one you are using.
You might be using local::lib to install modules in your home dir. local::lib causes the "install base" option of the standard module installers to be used. Unfortunately, while specifying the "install base" can be used to install modules in your home dir, it does so in in a way that assumes that you only ever use one perl
.[1]
Assuming you use only one perl
and that it was recently updated, you can fix your problem by deleting ~/perl5
[2] and reinstall the modules you had locally installed.
What if you have more than one build of Perl or you don't want to have this problem the next time you upgrade Perl?
There are ways of telling the installers to install modules in your home dir in such a way that multiple builds of Perl can share the installation directory,[3] but it doesn't really work.[4]
This is why I use perlbrew
to install Perl itself in my home dir so I don't have to override the installation location of modules. Using perlbrew
has the following benefits:
- You can have multiple builds of Perl installed without hassle.
- You can upgrade Perl when you want to, independent of OS updates.
- You can test scripts and modules with newer versions of Perl before switching to using it "permanently".
- You can test scripts and modules with older versions of Perl.
- ARGH! Why is this the default for local::lib to use?!
- Well, rename it until you're sure you're done with it.
- By using the "prefix" and "lib" options instead of "install base".
- You get into problems when a pure-Perl module depends on an XS module. Ok, so that's why local::lib doesn't take this approach.