The general consensus was to re-install the Perl modules. Thanks to all who replied: Karl Vogel" <vogelke@dnaco.net> Fabrice Guerini <fabrice@life.net> "Doug Hubbard" <doug@trackmaster.com> Hindley Nick <nick.hindley@lbhf.gov.uk> lupe@lupe-christoph.de (Lupe Christoph) Glenn Harrison <glennharrison@amcorp.com.au> "Thomas M. Payerle" <payerle@physics.umd.edu> Yura Pismerov <ypismerov@tucows.com> Larye Parkins <LParkins@niaid.nih.gov> "Vandevegt, James Matthew (Jim)" <vandevegt@avaya.com> Karl Vogel" <vogelke@dnaco.net> http://cpan.org/misc/cpan-faq.html How do I install Perl modules? Installing a new module can be as simple as typing perl -MCPAN -e 'install Chocolate::Belgian' http://search.cpan.org/author/JHI/perl-5.8.0/lib/CPAN.pm The CPAN.pm documentation has more complete instructions on how to use this convenient tool. If you are uncomfortable with having something take that much control over your software installation, or it otherwise doesn't work for you, the perlmodinstall documentation covers module installation for UNIX, Windows and Macintosh in more familiar terms. Fabrice Guerini <fabrice@life.net> If I were you, I'd just reinstall them. It's easy. Run # perl -MCPAN -e 'shell' and type install Net::Ping install Net::Telnet::Cisco install Net::FTP install Tie::SecureHash install Proc::ProcessTable install Date::Calc install Data::Dumper >One more question... how does perl know >where these modules are located.? I know >how perl is calling them Use Net::Dumper. I >am not sure how perl knows that the >Data:Dumper module is in any of the four >paths mentioned below? Just like your shell uses the $PATH environment variable to determine which "ls" command to exec, Perl uses the @INC array to search for modules and packages. "Doug Hubbard" <doug@trackmaster.com> My advice would be to download the latest packages from CPAN and reinstall them cleanly. It is during the make install OF THE PACKAGE that the @INC array is updated for perl so it knows that the package is installed. There may also have been bug fixes since the packages were installed on the previous machine. All in all I prefer to just reinstall the packages and know I have a clean solid setup (especially since you said this is a new box, why inherit any quirks that may be on the old one) Hindley Nick <nick.hindley@lbhf.gov.uk> If I were you I'd download and reinstall the modules: i. bugs are fixed all the time and its often better to get the latest versions ii. the perl modules tend to have a good idea of what the original configuration of perl was when they were installed. Its often difficult to reproduce the exact configuration lupe@lupe-christoph.de (Lupe Christoph) ... ... > Can I just copy everything by hand > from the old machine? No you can't. You could never be sure if something was branded with a 5.005_03-ism. Besides, this is the opportunity to update. Some Perl modules had security patches in the past. > I am not sure why, > however, some of them are on multiple > locations on the old machine: > old system: > Tie::SecureHash; = SecureHash.pm > /usr/local/bin/Tie-SecureHash-1.03/SecureHash.pm This is not a normal Perl library directory. What do the @INC's in 5.005_03 and in 5.6.1 show? > /usr/local/bin/Tie-SecureHash-1.03/blib/lib/Tie/SecureHash.pm blib is a directory that gets created when a module is built. It should never appear in the installation directories. Search and destroy all blibs. /usr/local/bin was misused as a build directory - destroy all subdirectories there that contain Makefile.PL's. > /usr/local/lib/perl5/site_perl/5.6.0/Tie/SecureHash.pm This looks like the real thing. But didn't you say 5.6.1? > One more question... how does perl know > where these modules are located.? I know > how perl is calling them Use Net::Dumper. I > am not sure how perl knows that the > Data:Dumper module is in any of the four > paths mentioned below? It looks in the directories in @INC (you see it with perl -V) for Data/Dumper.pm. > Is that information built into perl when you > compile the module using "perl Makefile.PL; > make, make test; and make install"? No, make install just puts the module files in places where Perl will find them. There are different places for modules that contain C code, etc. Perl autoloading is quite sophaisticated. Glenn Harrison <glennharrison@amcorp.com.au> I'd download all the module sources and compile them in properly again. Make sure you get the correct versions though, as some modules change syntax and functionality as they move up version numbers. "Thomas M. Payerle" <payerle@physics.umd.edu> Your best bet is to reinstall/remake from CPAN sources. This will also probably get you new and hopefully improved versions. Alternatively, if you still have the original sources, you can try reinstalling with that, but the more up-to-date sources are probably better. Yura Pismerov <ypismerov@tucows.com> You will have to reinstall all the modules. Larye Parkins <LParkins@niaid.nih.gov> or the least hassle, download the source packages from CPAN and make and install them separately: if you use the CPAN module, it will try to upgrade you to the latest Perl distribution, which is hours of work and confusing if it completes at all. When Perl is compiled, it knows where its modules are kept. It is not uncommon to have Perl 5.005xx, Perl 5.6.1, and Perl 5.8 on the same system, or multiple instances of the same Perl version with different sets of modules. Many web-based applications come with their own version of Apache and Perl, for instance. You can also use the -I option in the shebang line to point to other module directories if you have special modules only used by certain scripts. You might use -I to test whether the old 5.005 modules will work with Perl 5.6.1 before you start building new ones, especially if you have custom modules. -- "Vandevegt, James Matthew (Jim)" <vandevegt@avaya.com> Definitely use the CPAN module to download and install the modules. It takes care of installing any dependencies and you get the latest versions of everything. It also ensures correct compiler and flags are used -- the same ones that compiled perl. ORIGINAL POSTING: Carlos Sevillano <carlos_sevillano@ureach.com> Solaris 2.6 Perl 5005.03/5.60 to Perl 5.6.1 I have an old system running perl 5005.03. At some point someone updated perl, just the perl binaries and libraries to Perl 5.60 (perl -v shows 5.60 - Pkginfo shows perl 5005.03). I am building a new system and need to migrate what they have perl-wise to the new system running Perl 5.6.1. The problem is that I ran into a buch of modules that were available under 5005.03 that I have to update on the new installation. These modules work with the Perl DBI and Perl DBD and many custom perl modules to act as an "application". What is the right way to migrate all these modules? Do I have to collect them from the CPAN and do a a native install ... can they be copied from the old system to the new one? Here are the modules in question: Net::Ping; Net::Telnet::Cisco; Net::FTP; Tie::SecureHash; Proc::ProcessTable; Date::Calc; Data::Dumper; The modules are not part of the standard Perl distribution, they are not available on the clean perl installation (some of them like Tie are, however, the SecureHash part is not). Can I just copy everything by hand from the old machine? I am not sure why, however, some of them are on multiple locations on the old machine: old system: Tie::SecureHash; = SecureHash.pm /usr/local/bin/Tie-SecureHash-1.03/SecureHash.pm /usr/local/bin/Tie-SecureHash-1.03/blib/lib/Tie/SecureHash.pm /usr/local/lib/perl5/site_perl/5.6.0/Tie/SecureHash.pm Net::Ping; = Ping.pm /usr/local/bin/perl-5.6.0/lib/Net/Ping.pm /usr/local/lib/perl5/5.00503/Net/Ping.pm /usr/local/lib/perl5/5.6.0/Net/Ping.pm Net::Telnet::Cisco; = Telnet.pm /usr/local/bin/Net-Telnet-3.02/lib/Net/Telnet.pm /usr/local/bin/Net-Telnet-3.02/blib/lib/Net/Telnet.pm /usr/local/lib/perl5/site_perl/5.6.0/Net/Telnet.pm Net::FTP; = FTP.pm /usr/local/bin/libnet-1.0703/Net/FTP.pm /usr/local/bin/libnet-1.0703/blib/lib/Net/FTP.pm /usr/local/lib/perl5/site_perl/5.6.0/Net/FTP.pm Proc::ProcessTable; = ProcessTable.pm /usr/local/bin/Proc-ProcessTable-0.27/ProcessTable.pm /usr/local/bin/Proc-ProcessTable-0.27/blib/lib/Proc/ProcessTable.pm /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/Proc/ProcessTable.pm Date::Calc; = Calc.pm /usr/local/bin/Date-Calc-4.3/Calc.pm /usr/local/bin/Date-Calc-4.3/blib/lib/Date/Calc.pm /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/Date/Calc.pm Data::Dumper; = Dumper.pm /usr/local/bin/perl-5.6.0/ext/Data/Dumper/Dumper.pm /usr/local/bin/perl-5.6.0/lib/Data/Dumper.pm /usr/local/lib/perl5/5.00503/Data/Dumper.pm /usr/local/lib/perl5/5.6.0/sun4-solaris/Data/Dumper.pm One more question... how does perl know where these modules are located.? I know how perl is calling them Use Net::Dumper. I am not sure how perl knows that the Data:Dumper module is in any of the four paths mentioned below? Data::Dumper; = Dumper.pm /usr/local/bin/perl-5.6.0/ext/Data/Dumper/Dumper.pm /usr/local/bin/perl-5.6.0/lib/Data/Dumper.pm /usr/local/lib/perl5/5.00503/Data/Dumper.pm /usr/local/lib/perl5/5.6.0/sun4-solaris/Data/Dumper.pm Is that information built into perl when you compile the module using "perl Makefile.PL; make, make test; and make install"? Carlos ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Dec 17 12:31:32 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:00 EST