I am trying to run a Perl script as a CGI script. When I run the perl script from cmd line, it runs perfectly well, but it shows the following error when I run it from my browser.
Storable object version 1.012 does not match $Storable::VERSION 1.010 at
C:/Perl/lib/DynaLoader.pm line 225.
Compilation failed in require at C:/Perl/site/lib/AsiaXMLUtils.pm line 20.
BEGIN failed--compilation aborted at C:/Perl/site/lib/AsiaXMLUtils.pm line 20
The perl script concerned has basically been designed to queue some job to a remote software.
In case it rings a bell, Line 20 in the mentioned file is :
use Storable qw(&retrieve &store);
Here are the things I have done :
I have checked the following pages on how to troubleshoot your CGI
script but haven't got around the problem.
I have checked that the perl versions are the same for my PC as well
that used for the software I am sending the script too. I guess had
that been a problem, I wouldn't have been able to run the script
from the commnad line either.
I have run a simple Perl CGI (hello world) script using the same basic html code, so I guess that means I am not putting the cgi files (or accessing them) at the wrong places.
I am running a deadline for finishing this task, and thought should ask what approach I should take to solve such a problem. I am new to Perl. Any cues to what I should read to get around the problem will be greatly appreciated. I cannot share the code anyways, since much of it is proprietary.
Storable is an XS module, which means that it has both C code in Storable.dll (or Storable.so on Unix) and Perl code in Storable.pm. That error indicates that the version of Storable.dll ("Storable object version 1.012") does not match Storable.pm ("$Storable::VERSION 1.010"). If you can run the script from the command line, that means that your webserver is either using a different version of Perl, or #INC is different, or possibly you have an extra Storable.dll in your webserver's directory.
Try to use nstore instead of store. This way, your file will be crossplatform.
Also, try to reinstall the Store module.
Here is how I was able to solve the issue, which btw wouldn't have been possible without the valuable inputs of Miguel Prz and cjm.
Regarding the Storable Module : After reading both the answers, I noticed that my pc had two versions of
Perl. I removed one of them. This got me around the "Storable object
version 1.012 does not match $Storable::VERSION" error. Sounds pretty lame, I know. But I thought I should let you know anyways. But then
I ran into another set of problems. This :
Can't locate
AJE/Constants.pm in #INC (#INC contains: C:/Perl/lib
C:/Perl/site/lib .)
From comparing with the #INC of the perl environment from the
command line (for which I found this SO post very useful), I
noticed that the #INC that my web server was using (consisting of only 2 directories as shown above) did not include
many of the directories in the #INC of the command line perl environment. This is where cjm's words came back to me! I then used use lib to add those files in my
perl script and that solved the problem!
Thank you for all the help!
Related
I call the program myfoo.pl, my first line is #!/usr/bin/perl.
When run from command line myfoo.pl I get command not found.
again when run using perl myfoo.pl it runs and completes. Not all my perl programs have this problem some run just using (path)/source.pl I ran head -1 myfoo.pl and got a print of my first line. no indication of problems.
Looking at the limited information you gave, I would say you are probably missing permission executable on the file myfoo.pl. To which the solution is to do
chmod +x myfoo.pl
It could also be a path to binary problem, that the perl binary is not located in /usr/bin/perl. In which case you need to figure out where it is, with which perl or where perl.
I suppose it could also be that the file myfoo.pl is not in your current directory, which it needs to be. Because of path settings, you also may have to execute it with
$ ./myfoo.pl
Because . is part of your path variable.
It is impossible to say for sure, because you are not answering questions, however. So when you eventually get around to answering questions, we may have more answers.
I have an issue with a Perl script and the CPAN Twitter module.
I have a script that runs speedtest, and am trying to post the result to Twitter.
I have managed to get my script running manually by running ./speedtest.pl from my user account, however when I try and run it using crontab I get an error.
I have installed Net::Twitter, File::HomeDir and Config::Tiny using
cpanm Net::Twitter
etc.
(Note: no sudo) I get the following error when I run my script from my local crontab:-
Can't locate Net/Twitter.pm in #INC (you may need to install the
Net::Twitter module) (#INC contains: /etc/perl /usr/local/lib/arm-linux-
gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-
gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf
/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /home/pi
/speedtest.pl line 99.
BEGIN failed--compilation aborted at /home/pi/speedtest.pl line 99.
Can someone please point me in the right direction? I suspect it has something to do with where Net::Twitter etc ended up but I've no idea how to fix it so that crontab knows where to find it.
speedtest.pl is here
The Perl installation that you run from the command line is different from the one run by the system when a crontab job executes
Try which perl, and then look at the output of the same command run under cron
There are a few ways to fix this, depending on the configuration of your system. The most obvious is to use the full path to your own copy of perl, but while that will probably get things going it is probably a bad idea
I think you may have installed Net::Twitter using your local account.
Logging into root & installing the module should fix this problem.
How do I provide #INC externally for the cover script that is part of the Devel::Cover module.
I want cover script to run by searching for libraries relative to where it is triggered.
Idea is to have cover as part of source, and whoever gets this should be able to run directly without concerning the libraries, which will be relative to where it is.
I tried to change the script and have a BEGIN block inside this which will push paths to INC.
It works fine, but changing a script is not so good. I want INC to have my relative paths when it is called.
I would say there are 2 ways:
1-st In the actual script use:
use lib '/home/foobar/code';
2-nd When you are calling the script do -I on the command line
(That's a capital i)
The last solution is the most temporary solution. Add a -I /home/foobar/code flag to perl when running the script.
perl -I /home/foobar/code script.pl
This will add /home/foobar/code to the beginning of #INC for this specific execution of the script.
We have a custom perl install (5.10.1) in /usr/share, and I tried to do a 'cpan -i' install of GeoIP2 here
After doing this, it seemed to install a lot of dependencies I couldn't keep track of, and since I've been getting an error
Subroutine IO::Socket::INET6::sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67
On most scripts that we run that uses a 'use' command. I've been trying to nail down which module eventually calls that, but not succeeded as yet.
After some research, one suggestion was to comment out the following lines of
/usr/share/perl5/IO/Socket/INET6.pm # (version 2.56, think latest is 2.72)
###commented out the following
###use Socket6 (
### qw(AI_PASSIVE inet_ntop inet_pton getaddrinfo
### sockaddr_in6 unpack_sockaddr_in6_all pack_sockaddr_in6_all)
###);
This has stopped the errors from appearing on various scripts. Does anyone know if this is safe to do (ie will it cause further problems later), and is there a better way to go (ie is it possible to just update that module, I'm guessing that would cause problems and break other stuff?). What would be the best method of getting the module updated correctly ?
This was a bug in IO::Socket::INET6 which was fixed in version 2.69 according to this bug report:
Subroutine main::sockaddr_in6 redefined at /usr/share/perl/5.14/Exporter.pm line 67.
...
Should be fixed in 2.69.
You can update the module using cpan with the command cpan IO::Socket::INET6 from the shell as root.
Easiest is just to stop using IO::Socket::INET6 at all. That was created a very long time ago, but a far better solution has been created using the core Socket module, being IO::Socket::IP. Furthermore, this latter module is now core also since the newly-released 5.20. it would be better to use that IO::Socket::IP as that is the new core-recommended way to achieve IPv4/IPv6 transparency from now on.
Doesn't work with other modules, but to give an example. I installed Text::CSV_XS with a CPAN setting:
'makepl_arg' => q[PREFIX=~/lib],
When I try running a test.pl script:
$ perl test.pl
#!/usr/bin/perl
use lib "/homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi";
use Text::CSV_XS;
print "test";
I get
Can't load '/homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Text/CSV_XS/CSV_XS.so' for module Text::CSV_XS: /homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Text/CSV_XS/CSV_XS.so: cannot open shared object file: No such file or directory at /www/common/perl/lib/5.8.2/i686-linux/DynaLoader.pm line 229.
at test.pl line 6
Compilation failed in require at test.pl line 6.
BEGIN failed--compilation aborted at test.pl line 6.
I traced the error back to DynaLoader.pm it happens at this line:
# 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.
my $libref = dl_load_file($file, $module->dl_load_flags) or
croak("Can't load '$file' for module $module: ".dl_error());
CSV_XS.so exists in the above directory
When you installed the module, did you watch the output? Where did it say it installed the module? Look in lib. Do you see the next directory you expect?
Look in ~/lib to see where eveything ended up to verify that you have the right directory name in your use lib statement:
% find ~/lib -name CSV_XS.so
Once you see where it is installed, use that directory name in your use lib (or PERL5LIB or whatever).
I expect you have a lib/lib in there somehow. The PREFIX is just the, well, prefix, and the installer appends other directory portions to that base path. That includes lib, man, bin, etc.
Personally I would suggest to use local::lib. :)
Try this instead:
'makepl_arg' => q[PREFIX=~/]
PREFIX sets the base for all the directories you will be installing into (bin, lib, and so forth.)
You may also be running into shell expansion problems with your '~'. You can try to expand it yourself:
'makepl_arg' => q[PREFIX=/home/users/foobar]
It would also be helpful if you included the commands you used to get the error you are asking about.
It looks from the error message ("at /www/common ...") that your script is a CGI or mod_perl script. The web server is probably not running as the user 'foo', under whose home directory you've installed the module - that could result in the web server being unable to read that directory.
It may also be running in a "chroot jail", which would mean that the directory in which you've installed the module may not be visible to the script.
In other words, just because you can see the module, does not mean that the web server, and therefore your script, can do so. You should check the relevant file permissions, and if the server is chrooted, whether your module directory is mounted within the virtual file system.
Does the file in question (CSV_XS.so) exist?
Does it exist at the listed location?
If you do:
set |grep PERL
What is the output?
Have you successfully installed other local perl modules?
I strongly suggest installing your own perl in your own home directory, if you have space. Then you can keep everything under your control and keep your own module set, as well as escaping if the admins are keeping you on an older version of perl. (Not to mention preserving yourself if they upgrade some day and leave out all the modules you are relying on.)