Re: Debugging module version conflicts

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]

Comment on Re: Debugging module version conflicts Select or Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]