Debugging module version conflicts

Random_Walk has asked for the wisdom of the Perl Monks concerning the following question:

Goodly monks,

I am having a problem when I connect eclipse/EPIC ide to my CVS repo. Various modules now have version conflicts and will not run in the IDE, here is a typical example when a locally developed module in CVS tries to 'use Time::HiRes (usleep)':

Time::HiRes object version 1.86 does not match $Time::HiRes::XS_VERSIO
+N 1.66 at C:/Perl/lib/DynaLoader.pm line 253.
Compilation failed in require at C:/.../lib/Local/Event.pm line 20.
BEGIN failed--compilation aborted at C:/.../lib/Local/Event.pm line 20
+.
[download]

my c:\perl\lib\Time\HiRes VERSION is '1.66'

I guess this is a conflict between a version in my repo and the local PC version though running ppm upgrade localy I find there is no more up to date version of Time::HiRes in active state. The CVS does have Linux and Unix modules too, all this has to run on AIX, Linux and *doze. Is it possible Autoloader is trying to pull in one of these ?

Why would autoloader not get a module from the same installed tree as the .pm comes from ? Is there an way to see where Autoloader is getting the conflicting version from ? I am stumped

Thanks in advance,
R.

Pereant, qui ante nos nostra dixerunt!

Comment on Debugging module version conflicts Download Code

Replies are listed 'Best First'.
Re: Debugging module version conflicts by almut (Canon) on May 21, 2007 at 14:04 UTC
Is there an way to see where Autoloader is getting the conflicting version from ? You can set the environment variable `PERL_DL_DEBUG` to 1 to have DynaLoader print out some info, among which - if you have a recent Perl - you should find the absolute path to the .so file (-> `dl_load_file`). To see the paths to the loaded .pm files, just print out `%INC` hash's values. Doing both at the same time (on my system) gives: $ PERL_DL_DEBUG=1 perl -MTime::HiRes -e 'print join "\n", values %INC' DynaLoader.pm loaded (/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi / +usr/lib/perl5/5.8.8 /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-threa +d-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/ +lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/ +vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl ., /lib64 /usr/lib64 /us +r/local/lib64) DynaLoader::bootstrap for Time::HiRes (auto/Time/HiRes/HiRes.so) dl_load_file(/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/ +HiRes/HiRes.so,0): /usr/lib/perl5/5.8.8/Carp.pm /usr/lib/perl5/5.8.8/warnings/register.pm /usr/lib/perl5/5.8.8/Exporter/Heavy.pm /usr/lib/perl5/5.8.8/Exporter.pm /usr/lib/perl5/5.8.8/vars.pm /usr/lib/perl5/5.8.8/strict.pm /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/Time/HiRes.pm /usr/lib/perl5/5.8.8/warnings.pm /usr/lib/perl5/5.8.8/AutoLoader.pm /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/Config.pm /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm [download]	[reply] [d/l] [select]
Re^2: Debugging module version conflicts by Random_Walk (Prior) on May 22, 2007 at 12:06 UTC
That did the trick. Some injudicious copying of perl addins from another machine had put the .dll but not the .pm into the CVS tree. The CVS code comes first in the path so the local .pm tried to load the wrong .dll out the CVS. This was obviously clear when I set the debug in a BEGIN block. Cleaned up the CVS tree and everything is now OK. Thanks a million, R. Pereant, qui ante nos nostra dixerunt!	[reply]
Re: Debugging module version conflicts by syphilis (Archbishop) on May 21, 2007 at 14:21 UTC
What do you get when you run: `perl -MTime::HiRes -e "print $Time::HiRes::XS_VERSION"` [download] and `perl -MTime::HiRes -e "print $Time::HiRes::VERSION"` [download] Looking at Hires.pm, it seems to me that $XS_VERSION and $VERSION should be the same, and I therefore expect that the above two commands both produce the same output - and that the output is an error message very similar to the one you reported. That being the case, it would appear that the object version (ie the version of the dll/so) is 1.86, whereas the version of the '.pm' file is 1.66. This usually means that there was a botched install of the module at some stage .... or perhaps a botched install of ActivePerl. (You haven't perchance installed build 819 over the top of an earlier 5.8 build ?). Mind you, I have no experience of eclipse/EPIC ... Cheers, Rob	[reply] [d/l] [select]
Re^2: Debugging module version conflicts by Random_Walk (Prior) on May 21, 2007 at 15:16 UTC
Hi Rob, one problem is it all works fine localy on the command line ... C:\Perl\lib\Time>set PERL_DL_DEBUG=1 C:\Perl\lib\Time>perl -MTime::HiRes=usleep -le "usleep 10;\ print $Time::HiRes::VE +RSION;\ print $Time::HiRes::XS +_VERSION" DynaLoader.pm loaded (C:/Perl/lib C:/Perl/site/lib ., \lib) DynaLoader::bootstrap for Time::HiRes (auto/Time/HiRes/HiRes.dll) 1.66 1.66 C:\Perl\lib\Time>perl -v This is perl, v5.8.7 built for MSWin32-x86-multi-thread (with 7 registered patches, see perl -V for more detail) Copyright 1987-2005, Larry Wall Binary build 813 [148120] provided by ActiveState http://www.ActiveSta +te.com ActiveState is a division of Sophos. Built Jun 6 2005 13:36:37 Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using `man perl' or `perldoc perl'. If you have access to + the Internet, point your browser at http://www.perl.org/, the Perl Home Pa +ge. [download] problem lies somewhere in the integration between my local Perl and something Eclipse/EPIC is snaffling from the CVS repo. I am trying to persuade Eclipse to set the PERL_DL_DEBUG env variable as almut suggested then perhaps I can find from where it is bringing in the wrong XS. Unfortunately my Eclipse debug dialogue is missing the 'Environment' tab. Cheers, R. Pereant, qui ante nos nostra dixerunt!	[reply] [d/l]
Re^3: Debugging module version conflicts by almut (Canon) on May 21, 2007 at 15:28 UTC
Unfortunately my Eclipse debug dialogue is missing the 'Environment' tab. You could also set it from within your script, e.g. `#!/usr/bin/perl BEGIN { $ENV{PERL_DL_DEBUG} = 1 } use Time::HiRes; # ...` [download]	[reply] [d/l]
Re: Debugging module version conflicts by Anonymous Monk on Jan 26, 2012 at 22:33 UTC
Old question, but for others who find this page: I've fixed this problem with Eclipse's EPIC plugin by adding the site/lib directory to the perl command-line like so: `Preferences -> EPIC Perl -> Perl executable: C:\Perl\bin\perl.exe -IC:\Perl\site\lib` [download] It looks like EPIC doesn't look at this directory by default, the error above occurred because EPIC only found the native (XS) library associated with the perl module Time::HiRes in the 'perl' area. But you're using an updated version of the library installed in the 'site' area.	[reply] [d/l]