Current: Perl 5.14.0, DateTime
 

I updated to current, which includes perl 5.14.0. In updating to the latest DateTime module (0.70) via cpan, I receive this:

Lots of them. The same error occurs when 'make test'ing manually from the DateTime tarball. I see that DateTime 0.70 has been reported to be OK with 5.14.0 on linux (in fact, there are no fails for it). I uninstalled perl, removed all the perl5 directories, reinstalled it, upgraded all the default modules. DateTime still fails like this. Maybe current's perl has been compiled with different options?

Is anyone else getting this?

Nope, it builds fine here

It is not specific to the DateTime module, it happens when I try to install some other modules, including DBIx::Class::PassphraseColumn. Most modules are fine, though.

I installed current on a new Virtualbox VM and was able to install DateTime fine. I even rsync'd all the *perl5* directories from the VM to the main computer (the one I'm having the problem with). DateTime gave the same error.

I reinstalled everything in /var/log/packages/. Same symptom.

I downloaded the DateTime tarball and compiled it manually under /tmp. It built fine but failed its tests with the same error ('./Build test'). The weird thing is that all its tests pass when I run them with 'prove t', so it's like the Build script isn't finding the modules under lib.

When I upgradepkg back to Perl 5.12.3, I can install DateTime fine, and './Build test' works. When I switch back to Perl 5.14.0, it goes back to failing. It looks like there's something about that perl-5.14.0 that is making 'Build test' not see the modules in lib that it's testing against, but it's not consistent, and it Just Works on a freshly installed current in a VM. I've no idea what I've done to make 5.14.0 behave like this, and I'm reluctant to do a fresh install of my main computer, particularly when a reinstall of everything in /var/log/packages didn't help. Everything works with 5.12.3.

If anyone has any suggestions, I can easily switch back to 5.14.0 to try them out - please!

This is "only if you want to" and, if so, "do at your own risk".

http://www.cpan.org/src/5.0/perl-5.14.0.tar.gz

The above (it used to -- I guess it still does) defaults when it installs to

/usr/local/bin/perl

Whereas Slackware's Perl resides at

/usr/bin/perl

http://www.perl.org/get.html#unix_like

It's been a long time since I've had 2 Perls onboard, one at each of those two locations.

You get to find out of any difference of or in the self compiled Perl at/in

/usr/local/bin/perl

Understand well beforehand though as, for instance, you might want to remove one of them and create sym links that point to the other one . . . and/or etc. ie as .txz "Slack" pkgs or am I ok with them not as .txz "Slack pkgs. etc. etc.

--
Alan.

P.S. I saw a Date::Time slackbuild on slackbuilds.org

But it's not the very latest Date::Time if I'm not mistaken.

--
Alan.

P.S. #2 Perl has its own "module search path" where it looks

is it in @ARGV ? I forget where it is. But it (said path) can be appended to in the case where modules exist in a location that is not currently in said module search path.

The above is in the case where module(s) do be known to exist but wasn't found by Perl.

perl.beginners nntp newsgroup or google group

--
Alan.

One should not need to set PERL5LIB before doing a 'make/Build test', and certainly not before installing a module from CPAN (not that you'd be able to know what path to even set it to). If that were even the case, why would I need to do it for 5.14.0 and not 5.12.3?

PS. It's DateTime, not Date::Time.

Hi. I don't know what the cause is in your case. I only mentioned search path since you indicated as to perhaps not finding:

Usually I only need to append to the search path only if I have a custom/personalized differently located lib/module folder. So most likely your search path is ok.

Maybe more on perl.beginners or etc. Or maybe not. Thanks. :-)

--
Alan.

P.S. This wouldn't have to do with that UTF8 ?

Are you boot the kernel the old school style as non UTF8 ?

Due it read "not a code reference at Dynaloader.pm line 213" or whatever.

Somehow, it expects to get a code reference at that point from that place. And something goes awry at that point. (not reading that mentioned line correctly?) (or, another for instance, said code reference never got created earlier on so that it could be accessed at that point?) (etc.?)

Thanks. :-)

--
Alan.

I boot the kernel with append=" vt.default_utf8=0". I don't know why that would make a difference but I'll try removing it and see if it does!

I think that *is* the old fashioned way (a non utf8 terminal).

It may not make a dif. But it wasn't all that long ago that Perl got some huge changes pertinent to utf8 (and had bugs in that area). Perhaps they're all worked out by now.

It didn't make a difference. I removed DateTime, upgraded to perl 5.14.0, and got the same errors when I tried to install DateTime again. I downgraded to 5.12.3 and installed DateTime fine.

I don't know enough about what CFLAGS is. (I think it may be a part of a development environment)

(That's an uppercase V up there).

The next two lines I copy/pasted from web page at 1st url below.

Without CFLAGS, all goes fine:

# unset CFLAGS; <snipped more commands>

(My comment: Turns out that you're not the only one)

http://www.gossamer-threads.com/list...porters/263222

http://www.google.com/search?q=Not+a...ient=firefox-a

--
Alan.

FWIW @INC is the (it's a perl array that holds the) include path (search path).

Next is a snippet from "perl -V" on my 12.2 Slackware box

Thank you for finding that thread - you have superior searching skills than I! The problem was the CFLAGS, after all. Unfortunately, I have to unset it - even remove it from /etc/profile.d/, it seems - when I install perl modules, but that's something I can live with.