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

Hi, I am new to Perl and have inherited a Perl module that currently runs fine on a HP Unix box with Perl 5.6.1. This Perl module uses Soap::Lite and HTTP: Cookies Perl packages and makes a call to a web service by passing in a xml message. I am trying to port this on a Linux with Red Hat 4.6 and Perl 5.8.6 already installed on the box and having a lot of difficulties in doing so.
When I tried to test this module, it complained about certain missing libraries messages similar to below:

fault_code -1 Can't locate HTML/HeadParser.pm in @INC (@INC contains: /opt/perl5/lib/5.8.6/i686-linux /opt/perl5/lib/5.8.6 /opt/perl5/lib/site_perl/5.8.6/i686-linux /opt/perl5/lib/site_perl/5.8.6 /opt/perl5/lib/site_perl .) at /opt/perl5/lib/site_perl/5.8.6/LWP/Protocol.pm line 47. Compilation failed in require at /opt/perl5/lib/site_perl/5.8.6/LWP/UserAgent.pm line 103.

To fix these, I downloaded the 5.8 version of

LWP package and LWP.pm

HTTP/config.pm

from CPAN and then copied these over. Our old server has these libraries already installed but with 5.6.1 Perl. Now I am running into another error

fault_code -1 500 Usage: $h->push_header($field, $val) at /opt/perl5/lib/5.8.6/MatcherClient.pm line 338

When I tried to step through the code, it goes through numerous lines of code and throws error at

[mSOAP::Trace::defaultlog(/opt/perl5/lib/site_perl/5.8.6/SOAP/Lite.pm:2388):

2388: printf STDERR "%s: %s\n", $caller, $msg; [4m DB<80> [m [1m
[mSOAP::Transport::HTTP::Client::send_receive: 500 (Internal Server Error) Usage: $h->push_header($field, $val)

Content-Type: text/plain

Client-Date: Sun, 08 Feb 2009 04:41:36 GMT

Client-Warning: Internal response

I am not sure what exactly is causing this. Can someone please help? Thanks
  • Comment on Issue in migration of Perl code from 5.6.1 to 5.8.6

Replies are listed 'Best First'.
Re: Issue in migration of Perl code from 5.6.1 to 5.8.6
by Corion (Patriarch) on Feb 09, 2009 at 17:06 UTC

    Most likely, when "copying over" things, you didn't catch everything, or you missed a crucial prerequisite that also needs copying over.

    "Copying over" is not the way to go about installing CPAN modules, especially not into your stock Perl.

    The best way is to compile your own Perl independent from the stock Perl, because the stock Perl is used to run your operating system and does not really belong to you but to the manufacturer of your OS distribution. With your own private Perl, you can use the cpan package tool to install additional modules for your Perl.

    If you elect to stay with the stock Perl, I recommend installing the needed modules by using the package manager of your OS, in your case that would be rpm. That way, you can be sure to get the versions that are most likely to be compatible with the rest of your system.

    The next best approach is to use the cpan tool to install the missing modules from CPAN into your stock Perl, or possibly using the PREFIX= setting with cpan and ExtUtils::MakeMaker to install the modules into a private directory.

    See Yes, even you can use CPAN and A Guide to Installing Modules

[reply]
[d/l]
[select]
      Thanks so much for your prompt response.
      If I understand right, stock perl is the Perl installed with the Linux? Should I then remove whatever I copied and start over?

      I would probably need to stay with the current standard installation (stock?) since that's what will be installed at the customer site and install required modules separately.

      If I want to use package manager to install those modules, where can I find the documentation? Does it also automatically install dependent modules?

      Between package manager and CPAN what approach would be better?How can I ensure that I have installed all the required modules? Thanks
[reply]

        Yes, what I called "stock perl" is the Perl that comes with your installation of Linux.

        In my opinion, you shouldn't remove whatever you copied, because the risk of you removing too much is high.

        If you plan on running the application with the stock Perl at the customer's site as well, it's good to test it locally first. This still doesn't make it really convenient because the customer might choose to upgrade the OS and then the stock Perl will get upgraded without you getting further notice.

        The package manager of your Linux distribution is documented in the documentation of your Linux distribution. While Perl is widespread and some distribution package managers are written in Perl, Perl has little involvement with Linux distributions and thus does not document Linux distribution package managers. A good package manager automatically includes all dependent modules, but I don't know whether that's the case for RedHat.

        In my first response, I listed the approaches in order of descending quality.

        You can only find out that you have installed all the required modules if your application runs flawlessly.

[reply]

Back to Seekers of Perl Wisdom