CGI::Session.pm file not present - perl

I'm working latest CGI module (version 4.3+) and when I try to create CGI:: Session objects in a pl file, it's throwing error saying Session.pm file not present. As it said Session.pm file is not existing in #INC. How come file missed and is there any fix for this.

Looks like CGI::Session isn't installed on your system. It's a separate distribution to CGI, so it needs to be installed separately.

Related

Perl - Can't load Expat.xs.dll

Dear all I try to get XML RPC running on Bugzilla. I installed all perl modules what has been described by mozilla. but when I like to access the perl cgi script http://localhost:8010/xmlrpc.cgi I get the following error.
Can't load 'C:/Strawberry/perl/vendor/lib/auto/XML/Parser/Expat/Expat.xs.dll' for module XML::Parser::Expat: load_file:the requested modul get not found at C:/Strawberry/perl/lib/DynaLoader.pm line 193.
I verified the mentioned dll file is existign at the place C:/Strawberry/perl/vendor/lib/auto/XML/Parser/Expat/Expat.xs.dll. Here I assume the dll may require other dependent dll and other perl modules. Apache log file does not show me any additional information.
Any hint what I can do?
I am using
Strawberry Perl v5.22.1 (64bit)
Bugzilla v4.4.11
Apache v2.4
Windows 10
I opened a bug on the mozilla page for bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1240367
The support answered me that strawberry is not supported for bugzilla v4.4 however I could solve the problem by copying the C:\Strawberry\c\bin\libexpat-1__.dll to C:\Strawberry\perl\vendor\lib\auto\XML\Parser\Expat\libexpat-1__.dll (same directory as Expat.xs.dll is located). After that the XML Parser stuff and Expat.xs.dll could be executed properly.
May be it helps for others. Regards
I think the right answer should be:
add the folders
C:\{PerlFolder}\c\bin\
C:\{PerlFolder}\perl\bin
to the path under environment variables.
where {PerlFolder} in your case is "Strawberry"
same pb, solved by adding perl\bin in path

Can't locate Config.pm in #INC

I have a Perl app on my development server that I would like to replicate on my local machine (mac osx). I'm not a perl programmer by trade (I'm a PHP/Rails developer), and the developer of this app is no longer around so I can't contact him for help. I've gotten pretty close to getting it to work. I was able to install all the packages using CPAN (at least I think I got them all) but I keep running into the following error:
Can't locate WebCNP/Config.pm in #INC (
#INC contains: /Library/Perl/5.16/darwin-thread-multi-2level
/Library/Perl/5.16
/Network/Library/Perl/5.16/darwin-thread-multi-2level
/Network/Library/Perl/5.16
/Library/Perl/Updates/5.16.2/darwin-thread-multi-2level
/Library/Perl/Updates/5.16.2
/System/Library/Perl/5.16/darwin-thread-multi-2level
/System/Library/Perl/5.16
/System/Library/Perl/Extras/5.16/darwin-thread-multi-2level
/System/Library/Perl/Extras/5.16 .
)
at webcnp_lib.pl line 30.
On the server, the app's file structure looks like this:
/var/www/cgi-bin (empty dir)
/var/www/conf
/var/www/error
/var/www/html (empty dir)
/var/www/icons
/var/www/perl (the config file is located in this directory)
- /WebCNP/Config.pm
/var/www/ssi (all the .pl files for the app are located here, including all the JS and CSS files)
Line 30 of /var/www/ssi/webcnp_lib.pl has the following:
use WebCNP::Config;
Any ideas what I could be doing wrong?
Just so you know I've copied the file structure of the app from my development server to my local machine and created a virtual host so that it points to the app's root directory (/var/www).
Thanks in advanced for any insight!
was able to fix this with a symbolic link
ln -s /path/to/my/app/WebCNP /Library/Perl/5.16/WebCNP
I take this isn't a module from CPAN.
I would be a bit hesitant to use a symbolic link. This will work, but you're basically linking in a file you have under your own control to the master /Library directory on MacOS X. You delete your file, and that link won't be pointing to anything.
You can use use lib to add directories that contain your modules to the #INC directory:
use lib qw(/path/to/my/app);
This will now include this path for module searches.
If you rather install the module itself, why not simply copy it into /Lbrary/Perl/5.16 itself? It's what cpan would have done. At least this way, you're Perl module directory isn't dependent upon a link that can be removed.
/var/www/perl isn't present in #INC, so Perl won't look there. The most common approach to solve this for CGI scripts would be to add the following to your scripts (but not modules):
use FindBin qw( $RealBin );
use lib "$RealBin/../perl";
I was able to fix this with a symbolic link
ln -s /path/to/my/app/WebCNP /Library/Perl/5.16/WebCNP
Not sure if this is the most elegant approach, but seems to work well for this app. Thanks everyone for your replies! This has been very insightful.
Old post, I know, but there is a much more portable way. When you install the modules, you need to do two things.
Add the installation path to PERL5LIB (i.e. PERL5LIB=$PERL5LIB:/My/Module/Path/lib) in your environment configuration (.profile or other files which get read on system initialization)
Add a PREFIX to your perl Makefile.PL call (perl Makefile.PL PREFIX=/My/Module/Path)
It goes without saying that you need to make certain your Makefile.PL is written correctly.

Can't load 'C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll' for module XML::LibXML

I have downloaded strawberry PERL and writing one application with CGI Perl Apache on Winxp sp3).
One of the libraries (written by someone else) which I using uses XML::LibXML. When i load the page it gives Internal Server Error. From Apache error log i can see this error:
Can't load 'C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll' for module XML::LibXML: load_file:The specified module could not be found at C:/strawberry/perl/lib/DynaLoader.pm line 190.
C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll exists with all permissions.
Also this library works properly on Linux. My application also works fine if I remove all code that needs LibXML.
Can anyone tell me when can be possible issue here.
If you peek into the source for DynaLoader you'll find
Many dynamic extension loading problems will appear to come from
this section of code: XYZ failed at line 123 of DynaLoader.pm.
Often these errors are actually occurring in the initialisation
C code of the extension XS file. Perl reports the error as being
in this perl code simply because this was the last perl code
it executed.
You should have also gotten (but may not have noticed) the following dialog, which provides a more accurate error message:
The problem isn't that perl can't find LibXML.dll; it's that LibXML.dll can't find the real libxml. (The former is just a wrapper that provides Perl bindings for the latter.) To fix that you need to ensure that Strawberry Perl's c\bin folder is in your PATH. In your case, that would be C:\strawberry\c\bin.
You might have to check the environment variable settings in the windows,
make sure that the installation path of the module is present in the PATH variable.
The reason it works in linux is that make files usually set the environment variables for you in linux in windows it may not have set properly.
For eg;
go to Control Panel\System and Security\System click change settings then advanced tab in user variable section see if there is a variable called perl5lib.
if not create an new perl5lib variable and add the path of your library ( usuall C:\Perl\site\lib but may be different in your case)
I had the same issue after installing Strawberry perl. It was working fine when I run the script from server, but not remotely from a automation tool. The issue was because of the Environment variables not updated when we run it remotely. So I did server reboot, which resolved the issue.
I encountered the same problem recently, in my case it was not related to PATH variable (it was already correct). The thing is I was executing my script from Git Bash console and as it turned out git-bash perl was being used instead of Strawberry (see git-bash perl should not be first in path). Switching to standard Windows CMD terminal helped.

Why doesn't my Perl script find my module even after I adjust #INC with FindBin?

I want to be able to use a module kept in the lib directory of my source code repository, and I want the only prerequisite for a developer to use the scripts that I'm writing is to have a standard Perl installation, but I'm not sure how to accomplish this.
In my scripts, I have
use FindBin qw($Bin);
use lib "$Bin/lib"; # store non standard modules here
use Term::ANSIColor;
use Win32::Console::ANSI;
print Term::ANSIColor::colored("this should be in color\n", "bold red");
and I put the module in ./lib. I verified that's the actual location where the module exists (by renaming it and causing it to fail). However, even if the module is in an arbitrary lib directory, it still seems to be a requirement that ppm be aware of the module.
I can not get my scripts to find/use it in lib without it being "installed" by ppm first. I would imagine that there should be some sort of way around this.
I know this may be an atypical request, but my goals are probably atypical. I just want a developer to do a checkout and immediately use some scripts without having to run some additional commands or use a package manager.
Thanks for any insight.
EDIT: I updated with a complete example. I also realized that if I uninstall it via ppm (but leave the pm in the referenced directory), I may have to change my syntax, and I was not considering that before. So maybe I have to give a full path or use require like jheddings or BipedalShark propose (ie. if it's not "installed", then I must use "require" and append ".pm" to it or use a BEGIN block.
If this is the case, then I have not found the correct syntax.
EDIT 2: Based on a comment below, I realize that I may have a flawed assumption. My reasoning is this: If I reference the actual code, the ".pm", directly then I should be able to use it without using a package manager. Maybe that's not the case, or if I want to do that maybe I have to do it a different way. Alternatively, I may have to refactor the code in the ".pm".
EDIT 3: I think that I was misunderstanding a few things. The error message in my IDE "Compilation failed in require", it's highlighting of the line that I was using to include the module, and the console error message of "Can't locate loadable object for module Win32::Console::ANSI"
I was reading that as a problem with loading the module itself, but it seems to be a problem that results from something the module itself is attempting to load. Interesting that this is only a problem since I didn't use ppm install though.
It is finding the actual module. I was able to verify that by commenting out the trouble lines.
Thanks for the help, but I'll have to spend some more time with it.
See perldoc perldiag under "Can't locate loadable object for module ...":
(F) The module you loaded is trying to load an external library,
like for example, "foo.so" or "bar.dll", but the DynaLoader module
was unable to locate this library. See DynaLoader.
You are correct that this problem is arising from something the module is trying to load -- that's what Dynaloader does. However, the documentation for Win32::Console::ANSI makes no mention of any external library requirements.
Are you preserving your module path structure in your lib directory?
i.e. your module should be in the path $Bin/lib/Some/Module.pm.
From perlfaq8's answer to How do I add the directory my program lives in to the module/library search path?
You appear to be doing it correctly, but you need to give us more if you expect to get help.
When you run that script, what ends up in #INC? Put in a debugging line like:
BEGIN {
use lib ...;
print "INC is \#INC\n";
}
Check that that output shows the directory that you expect. If it doesn't, start bisecting the problem from there.
Try this:
BEGIN {
use FindBin qw($Bin);
}
use lib "$Bin/lib"; # store non standard modules here
I manually install modules all the time and it seems to work. I just copy directories and files into a location and use the "use lib" directive like you've shown. Sometimes I miss a file and I get a runtime error that it's looking for a certain file and I go find the file on the Internet and put it in the right place and it works. Not sure what's going on with your setup. This should work.
I usually put the perl modules in the same directory as my script and then: use lib "."
But I don't know that it would matter.

How can I force Perl to run the module from the test directory only?

I have perl module file and test script pl which I use to run some function, and after browsing through the use lib and this previous question here...
I still don't know how to do this.
Basically I have a production directory which contains the module file, and I have a test directory file which contains the same module and the test script file. each time I try to run the script file, it will automatically calls the module in the directory. by printing out the #INC, it seems that the production directory is hosted in there. thus I try to remove it by using
no lib qw(prod_dir);
and while printing out the #INC shows that the directory is no longer there, somehow the script is still calling that other module...
I know this probably sounds really dumb, but hope someone can help me see the light here :)
thanks.
After you have required or used the module, check %INC to see where it came from.
For example:
use Data::Dumper;
print $INC{'Data/Dumper.pm'}."\n";
Note that "::" becomes "/" and you append ".pm". That might give you a clue.
Remember that the current directory (".") is usually an entry in #INC. But the first step is finding out what directory the module was loaded from.
Another thing to remember is that the directories in #INC are searched in order. use lib prepends to that list (making it the first-searched directory), so you may just need to add the appropriate directory.
Can you say more about what you are trying to do and how you are trying to do it? Is this stuff in a standard Perl distribution structure? If you aren't using the standard distribution structure, can you show us a directory listing so we know where things are? Can you also include the code you use to try to load the module? Just update your original question when you pull together the details.
Typically, I run tests through the build runner, which automatically sets up the right #INC.
If I want to run one test in my distribution, I use the blib module to find the build library which has the development versions of my modules:
% perl -Mblib t/test.t
Some people do the same thing with prove.
If you aren't using the basic distribution set-up, consider using it. The tools and best techniques rely on it.
If you just have your module and test file in the same directory, have you tried adding the current directory to #INC with PERL5LIB?