eval "require $backend; $backend->import(); return 1;";
[download]

eval "require $backend; $backend->import(); return 1;" or die $@;
[download]

perl -E'require Date::Manip; say $INC{"Date/Manip.pm"};'
[download]

Thanks for your reply. Your suggested tweak to Date/Manip.pm didn't make any difference.

But after some other hacking, and making sure my Arch Linux system is fully up to date, I now get:

Perl API version v5.14.0 of Storable does not match v5.16.0 at /usr/sh
+are/perl5/core_perl/XSLoader.pm line 92.
Compilation failed in require at /usr/share/perl5/vendor_perl/Date/Man
+ip/Obj.pm line 13.
BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/Date
+/Manip/Obj.pm line 13.
Compilation failed in require at /usr/share/perl5/vendor_perl/Date/Man
+ip/Date.pm line 14.
BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/Date
+/Manip/Date.pm line 14.
Compilation failed in require at ./brandysnap line 41.
BEGIN failed--compilation aborted at ./brandysnap line 41.
[download]

A bit of Googling reveals that 'Storable' ought to be part of core 5.16, so I don't know how to start fixing that.

Perl API version v5.14.0 of Storable does not match v5.16.0 at /usr/sh
+are/perl5/core_perl/XSLoader.pm line 92.
[download]

It is kinda sad that this particular error gives you details about the full paths to a bunch of files but doesn't bother to include the two full paths that actually would be useful for diagnosing the problem. That is, it should tell you the full path to Storable.pm and to Storable.so (or whatever dynamic library it found to load).

But, since the paths that it reports include

/usr/share/perl5/core_perl/XSLoader.pm
/usr/share­/perl5/ven­dor_perl/D­ate/Manip/­Obj.pm
[download]

It seems clear that the instance of Perl you installed puts module files into a directory structure that is not specific to one version of Perl. That is a very old idea that I find, these days, is just never worth the headaches it causes.

Likely, the version of Storable.pm that you wanted either got overwritten when a different version of Perl was installed (that stupidly shared the same /usr/share/perl5 directory structure) or (seems less likely) just gets ignored because the version of Storable.pm that you don't want gets found first due to the order of directories listed in @INC.

My suggestion is to uninstall all versions of Perl except the one included with the operating system, force a re-install of the Perl included in the operating system, and make sure that any other versions of Perl that you install don't touch nor look at any of the directories where the system Perl stores modules.

- tye        

I cannot reproduce your bug here. I have both perl 5.14 and perl 5.16 installed via perlbrew, and have now installed Date::Manip. Your oneliner works fine on both perls. (System: Debian GNU/Linux testing, amd64).

Did you, by any chance, install a pre-packaged module (versus one installed from source by the cpan shell or similar)?

Try to reinstall the module. If cpan install Date::Manip says it's current and it still doesn't work (had something similar a few times with ActivePerl), try this to see whats going on:

cpan
look Date::Manip
perl Makefile.PL
make test 

make install 
# Might have to use sudo make install
# (depends where your perl modules are installed)

make distclean
exit
exit
[download]

#!/usr/bin/perl 

BEGIN {
    $| = 1;
    $ENV{'DM6'} = 1;
    $ENV{'TI_MODE'} = 'inter';
}

use strict;
use autodie;
use warnings FATAL => 'all';

use CPAN;
use Test::Inter;
use Date::Manip;

my $t = new Test::Inter;

$t->feature( print "Perl: $]\n" );
$t->feature( print "OS: $^O\n" );

if ( $Test::Inter::VERSION eq 1.03 ) {
     $t->feature( print "Test::Inter: ", $Test::Inter::VERSION, "\n");
}
if ( $Date::Manip::VERSION eq 6.32 ) {
    $t->feature( print "Date::Manip: ", $Date::Manip::VERSION, "\n");
    $t->feature(print Date::Manip::ParseDateString("10:20"), "\n");
}
else {
    CPAN::Shell->install(
    Task::DualLived
    Test::Inter
    Date::Manip));
}
[download]