in reply to Re^7: Module Path Problem
in thread Module Path Problem

ya i got it bt i think the problem is file permission because everytime when i use it i get this, its the only module which is not install at the server, so when i try to remove it from my script the page works very well with other modules installed on the server Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log.

Replies are listed 'Best First'.
Re^9: Module Path Problem
by MidLifeXis (Monsignor) on Nov 18, 2014 at 19:38 UTC

    More information about this error may be available in the server error log.

    And what does the server error log say? Apache (and possibly IIS?) store output generated to STDERR in the server's error log. This information will usually contain more useful information than just "it didn't work". Try also adding use CGI::Carp 'fatalsToBrowser'; to the top of your script. Make sure that you remove this in production, as it can leak information that you do not want to provide an outsider.

    --MidLifeXis

      i checked the log Can't locate Moose.pm in @INC (@INC contains: . /usr/local/lib/perl5/5.8.8/i686-linux /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/i686-linux /usr/loca

        Is Moose installed? You may need to determine what modules you must have in a library path local to your application, and install those along with your application. See local::lib as a possible mechanism to do this. Alternatively, you can ask your vendor to install Moose (and every other module you want to use) for your application.

        Once you have taken care of getting all necessary libraries available to your application, you will want to mull on whether or not you really want to tie your application to your OS's version of Perl. The OS version of Perl is tied to the OS's expectations. Changes to the OS version of perl to benefit your application can break the OS tools, and changes to the OS version of perl to benefit the OS tools can break your application. Decoupling your application from the OS is (at least in my opinion) a big win for anything larger than a toy script.

        Your OS is also running a very old version of Perl. Some commonly used libraries do not even target anything below 5.10. You may want to ask your vendor if there is another version of Perl on this platform.

        --MidLifeXis