Getting below Error: using an array as a reference is deprecated in perl script at line
Please Suggest, What is wrong in below code.
$sqlsyntax="exec Stored_Procedure,\#ErroeCode='$ErrMsg`";
#ret = $dbh->nsql ($sqlsyntax,"ARRAY");
my($EntityId,
$MaturutyDate);
my($size,$index,$count);
$size=scalar #ret;
$index=0;
$EntityId=#ret->[$index][0];
$MaturutyDate=#ret->[$index][9];
This perl is working fine in Solaris but when same is migrated to Linux environment, it is giving this error.
Getting below Error: using an array as a reference is deprecated in perl script at line
During Compilation it is giving this error, Want to fix this in Linux environment.
I'm not sure where you're getting this code from, but it uses a very old version of Perl syntax that you shouldn't have been using for a very long time. [Update: As ikegami points out in a comment below, this isn't very old Perl syntax - it's syntax that only worked because of a bug in Perl and which shouldn't have ever been used.]
#ret->[$index][0]
This code uses the fact that an array can (in certain circumstances) be used as an array reference. You should not do this, as there are other (simpler) ways to do the same thing. This syntax is, as you see, deprecated.
Your code should be written as $ret[$index][0]. If you change it to be like this, then the warnings will go away.
Update:
This perl is working fine in Solaris but when same is migrated to Linux environment, it is giving this error.
I imagine that's because your Solaris system is running a far older version of Perl. What do you get from running perl -v on both of your systems?
Related
I've searched a couple of topics about this issue, and in the exact same context (running diogenes on linux) on the following link, but it was closed due to vagueness in the submission:
Running old perl script (2007)
So, the error message is this:
Can't use 'defined(#array)' (Maybe you should just omit the defined()?) at /usr/local/diogenes/perl/CPAN/CGI.pm line 449.
Compilation failed in require at ./diogenes-server.pl line 42.
BEGIN failed--compilation aborted at ./diogenes-server.pl line 42.
At line 449 in CGI.pm there is this:
if (defined(#QUERY_PARAM) && !defined($initializer)) {
So reading up a bit, it seems that this code is wrong and it has been deprecated in newer version of perl. Being Diogenes such an old software it seems correct. So, how can I rewrite this in order to move on.
Lastly, i am following this tutorial on how to run diogenes on linux and have no clue about perl programming:
http://community.dur.ac.uk/p.j.heslin/Software/Diogenes/linux_install.php.
:)
As documented in defined (and mentioned in the error message), try changing this:
if (defined(#QUERY_PARAM) && !defined($initializer)) {
into this:
if (#QUERY_PARAM && !defined($initializer)) {
The problem isn't really Diogenes itself. The problem is that Diogenes has packaged up all of the CPAN modules that it uses and that includes a version of CGI.pm from 2004.
That wouldn't be a problem, except that you're running this on a far newer version of Perl - Perl 5.22 or greater. The perldelta for Perl 5.22 includes this:
defined(#array) and defined(%hash) are now fatal errors
These have been deprecated since v5.6.1 and have raised deprecation warnings since v5.16.
So what's happening here is:
Diogenes includes a really old version of CGI.pm which uses deprecated syntax.
Diogenes doesn't include a version of the Perl compiler.
You are now using a version of Perl which has turned this deprecated syntax warning into a fatal error.
It looks like you have three options:
Downgrade to an earlier version of Perl (pre-5.22) which will just warn on this syntax.
Remove the Diogenes-installed copy of CGI.pm and install a recent version of CGI.pm from CPAN (version 3.60, released in 2012, fixed this bug).
Hack your Diogenes-installed copy of CGI.pm to replace defined(#QUERY_PARAM) with just #QUERY_PARAM.
In a comment, you mention trying the last suggestion on my list and getting a different problem. It looks like that's also caused by changes in Perl syntax (this time, regex syntax) in the twelve years since Diogenes was last updated. And, of course, it's possible that fixing that will just reveal another, similar, problem.
All in all, it might be worth contacting the author of Diogenes and explaining the problems you're having using the software with modern versions of Perl. Even if the author doesn't have time to fix the problems, it's possible that they could add a warning to the web site, telling people about these problems.
Try changing it to exists.
This also works if the purpose is to test for non-emptiness:
if (#QUERY_PARAM && !$initializer) {
I copied a Perl module (DBD::Pg) from one system to another to run some quick checks on a Mojolicious project. On the new system, it all works fine when I run it under morbo (the Mojolicious test web daemon). But when I try to run the tests (via the Module::Build installer), I get the error:
Perl API version v5.16.0 of DBD::Pg does not match v5.20.0 at /usr/local/lib/perl/DynaLoader.pm line 216.
I researched why I am getting this, and read the explanation in the perldoc. But since the project runs under morbo, that seems to imply to me that the version mismatch may be trivial in this case. It looks like PerlXS does make some allowances for disabling VERSIONCHECK, but I don't see how that can be applied when running a Perl script.
You can't copy non-pure Perl modules from one system to the next (or into one group of perl lib directories into another perl's). Generally the code in those modules is compiled against the specific perl binary. That binary could have linked to different libraries, changed how it does things, used a different compiler, and many other things. It may not even work if the perl versions are the same.
Instead, install the DBD::Pg for each perl that needs to use it.
I'm trying (desperately) to build / install the newest version of WWW::Curl onto my activeperl box (I'll explain in a moment why I don't use the PPM)
I had to make some modifications as per the instructions found here:
http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/README.Win32
I also had to change the following line:
From:
open(H_IN, "-|" "gcc", "$curl_h") and $has_cpp++;
To:
open(H_IN, "gcc $curl_h") and $has_cpp++;
I finally got perl Makefile.PL to work but now, when I run nmake, I get the following:
Missing right curly or square bracket at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
NMAKE: fatal error U1077: 'C;|windows\system32\cmd.exe' : return code '0xff'
Stop.
Now, the reason I'm trying to compile this rather than using the PPM supplied by u.winnipeg is because the that PPM doesn't seem to support SSL transaction (I get "libcurl: ssl disabled") Now, if anyone can show me how to get ssl to run on this PPM, I'm more than happy to use it.
Thank you very much in advance
I presume the original was
open(H_IN, "-|", "gcc", "$curl_h")
The reason you have to change that in because noone got around to implementing feature in Windows. Change it to
open(H_IN, qq{gcc "$curl_h" |})
Use the right name and syntax for your compiler.
Well, I finally figured it out, thanks to everyone who responded. There were a bunch of things I had to change.
Using http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/README.Win32 as a guide:
The open cmd as I did above worked fine. However, I did use the advice returned by ikegami, reinierpost, and mob.
Using nmake /n (as advised by socket puppet), it printed out all of the perl statements which were being executed. I took this output and placed it into a .bat file and corrected the perl syntax.
I changed all instances of
pm_to_blib({{#ARGV}
to
pm_to_blib({#ARGV}
(it is disturbing these were returned)
Then, I had to link the libcurl libraries to each line instantiating g++, which were not linked correctly. After I added these references, everything else went smoothly.
These were added:
C:\lc\curl\lib\libcurl.a C:\lc\curl\lib\libcurldll.a
Now, WWW::Curl is happily running on my system.
As for using the PPM version, it is exactly because of SSL I had to upgrade. The newest version of WWW::Curl is 4.15 the ppm version is (I believe) 3.02.
First, many people don't know that you can use ppm to install MinGW to use cpan to install modules.
Second, if the libcurl provided by your module doesn't do SSL, you can try and replace it with a suitable SSL version from the download page. This might well fail, but you might also be lucky.
I have a C++ object that I am converting to Perl using Perl XS. This process works fine with Perl 5.8.5 and 5.8.7. But as soon as I try to use Perl 5.10.0, I run into a lot of compile errors. Most of them are along these lines:
undefined reference to 'PL_stack_max'
undefined reference to 'PL_stack_sp'
undefined reference to 'Perl_sv_2pv_flags'
undefined reference to 'Perl_sv_setref_pv'
That tells me that for some reason the Perl XS stuff isn't being linked in properly. When I went from 5.8.5 to v5.8.7, I just had to change the version and make again.
Any tips?
Did you recompile the XS extensions when you moved to 5.10.0?
Did you set Perl 5.10.0 to maintain backwards compatibility when you built it? (Is that even possible? I've never tried to build backwards compatibility, so I can't be sure it is even an option, and #Ysth thinks it is not.)
I've seen similar problems when working between main versions of Perl, but not sufficiently recently to be confident of exactly what causes the problem. But I seem to remember that somewhere near the end of the configuration process there is a question about which previous versions of Perl to be compatible with for XS extensions, etc.
I was using 32bit Perl 5.10.0 on a 64bit machine. Problem solved!
Thanks to everyone who responded.
I'm developing an application using Perl 5.10, HTML::Mason, and apache 2.2. This is the first time I've used Perl 5.10 for a big project. I get a strange behavior every once in a while. The application dies with a very strange error:
panic: attempt to copy value
to a freed scalar b87acf34 at ...
I guess my question is it Perl 5.10 because I've never experienced this before, or is it some other faulty dependency?
Thanks a lot!
Not sure if this has anything to do with your error (probably not), but mod_perl+mason+perl5.10 is a no go. Perl 5.10 introduced at least one big bug that leads to segmentation faults under some conditions: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480480#24