> Op zo 15 januari 2012 om 23:57:38 (+0530) schreef > sridhar.dachepe...@gmail.com (Sridhar Dachepelly): >> Hello, >> >> I am trying to use DBI module in Windows 2010 server, i have installed perl >> 5,14 version (64-BIT). DBI module is not working and giving errors. >> Could you please look into the below errors and suggest what we can do for >> the same. > > [...] >> Perl lib version (v5.8.6) doesn't match executable version (v5.14.2) at >> C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/MSWin32-x86-mult >> i-thread/Config.pm line 32. > [...]
Others have already explained what is wrong -- your computer has multiple versions of Perl (which is OK), and one version is calling libraries of another version (which is not OK). Make sure the Perl you are using is using the modules compatible with it, and you will be fine. I will try to explain how this error can come to happen. Usually, when you install Perl, all the modules that get installed with it are installed correctly to be used by it. When you install new modules after the fact, they too get installed correctly respective to the Perl you used to install them. So, imagine I have (unix examples ahead, but the logic would apply for Windows as well) /usr/bin/perl5.8.6 (aka p1) and /opt/local/bin/perl5.14.1 (aka p2)... if I install modules using `p1 -MCPAN -eshell` then they will get installed under /usr/lib/perl whatever, and if I install modules using `p2 -MCPAN -eshell` they will be installed correctly for p2 under /opt/local/lib/perl etc. Now, the modules that are used depend on the perl that is used. So, if your program explicitly calls `#!/usr/bin/perl` then it will use modules under /usr/lib/perl and if your program calls `#!/opt/local/bin/perl` it will use the modules under /opt/local/lib. The problem happens if either a different perl than what you expect is hard-coded in some program, or you are making some implicit calls, such as those by `#!/usr/bin/env perl`. For example, the latter is dependent on what it finds using /usr/bin/env, which would be different when run in a shell than when run in some other context. Moral of the story -- there is nothing wrong with having multiple perls... in fact, feel free to use something like perlbrew to install and control your own custom perl or many of them. Just make sure the perl you are using is using the modules that match it. -- Puneet Kishor
