Compilation failed in require when using "use" in Perl - eclipse

I am using Perl in Eclipse.
In the same directory, I have a .pl file and two .pm files (pmFile1.pm, pmFile2.pm).
At the top of the .pl file, I use the command:
use pmFile1;
use pmFile2;
I get an error
Compilation failed in require
I do not believe I had this error earlier. I have researched this error online, and cannot figure out what may have caused it, because I have not found a similar situation to mine that caused the error. I do not know what other information would be pertinent to include, but will add anything if asked...
Thank you.

I suggest you check the module pmFile1.pm for errors in a terminal shell
$ perl -c pmFile1.pm
syntax error at pmFile1.pm line 1, near "."
pmFile1.pm had compilation errors.
When entering a single dot . as a syntax error into pmFile1.pm and running the p.pl file then the errors below are shown in Eclipse, the same as you described. If you run the .pl file in a terminal shell then you get the same compilation failed in require as in eclipse:
$ perl p.pl
syntax error at pmFile1.pm line 1, near "."
Compilation failed in require at p.pl line 1.
BEGIN failed--compilation aborted at p.pl line 1.

This may not be your problem, but I've been "bitten" by something similar before: check the End of Line chars in the file. It may be that your code is seen by the compiler to be all one line, making an error anywhere in the code appear as being on line 1 when visually (in the editor) the offending line would be later in the code. In notepad++ you resolve this sort of issue by using the Edit > EOL Conversion > Windows Format (or whatever format is correct for you) menu option, though other editors will likely have a similar feature for *NIX <-> Windows EOL conversions. This error would make sense if you can successfully use the module files giving you an error without errors in other script files.

I solved this by changing the required package to some dummy name, then retaining it.

Related

Unrecognized character \x90 ERROR in perlcode.exe

Unrecognized character \x90 at line..
I am getting above error while executing perlcode.exe, But when it is executed as Perl (i.e perlcode.pl) it works like a charm. And, I am surprised I haven't seen any such error in Google. Any help appreciated.
The input file is a LaTeX file which may or may not have Unicode.
Why is .pl working, but .exe is not working?
What is meant by the ERROR: Unrecognized character \x90 at line..?
Note that use utf8; is used in the Perl script.
I had this problem when I wasn't thinking straight. I had compiled the .pl file with perl2exe but was running the command
perl c:\tmp\myexe.exe
Obviously you don't need to have perl at the start - just run the exe
To change the perl code to an .exe file, you'll need to compile it. If you are saying that the pl code works allright, but the exe not, maybe that it's the issue.
One of the options is to use pp to do it. You can find it here.
its a typo mistake which has been made in a batch file while calling exe.

Pintos installation SIGVTALRM() redefined error

I got no error during installation, all make commands worked perfectly but in the end when I run "pintos run alarm-multiple", I'm getting the following error
Prototype mismatch: sub main::SIGVTALRM () vs none at /home/suhas/bin/pintos line 949.
Constant subroutine SIGVTALRM redefined at /home/suhas/bin/pintos line 941.
Writing command line to /tmp/k5qCPWWL5b.dsk...
squish-pty bochs -q
exec: No such file or directory
Any help would be highly appreciated. Thanks.
This is a simple task. Just go to the file /home/suhas/bin/pintos and comment out the whole function SIGVTALRM(). It should work fine. Even I had the same error.

SOAP::Lite always faults in debug mode

I've had this issue for a while now. Every time I use SOAP::Lite in debug mode (whether normal debugging or with something like NYTProf) it ends up calling the on_fault handler.
I've stepped through and it is due to this error:
Attempt to reload SOAP/Lite/Deserializer/XMLSchema2001.pm aborted.
Compilation failed in require at (eval 1343)[C:\\Perl\\site\\lib/SOAP/Lite.pm:2328] line 3.
...propagated at C:\\Perl\\site\\lib/SOAP/Lite.pm line 2328.
I'm wondering if this is normal and what the best workaround is? Thanks.
Edit: Forgot to mention this is Activestate Perl 5.10.1 on Windows and upgrading is not an option at this time.
Found it! Running perl with both -d and -w flags seems to cause an issue in the debugger with the scope of warnings. It complains about redefined subs in this mode, but ignores them if we supply just one or neither of the -d/-w flags.
The issue is in SOAP::Lite::Deserializer::XMLSchema2001, the BEGIN block maps the as_* methods. dateTime is in the list twice so we get an error about as_dateTime being redefined.
This breaks the initial module compilation, and upon our 2nd attempt produces the error above.

/usr/local/bin/perl5: bad interpreter: Permission denied

I have a unix command
(script) which has a nested perl script in it.
when i run this unix command from command line it works fine.
If I am running same command from a tcl file using exec, i am getting following error:
'sh: /cmdpath/cmd.pl: /usr/local/bin/perl5: bad interpreter: Permission denied'
Any Idea what could be causing this. My tcl code is trying to execute this command several times ( more than 100 times).
Thanks
Ruchi
Almost certainly your Perl script is encoded in DOS/Windows line-ending format, which uses \r\n to terminate lines. Since Unix terminates lines with \n only, the \r is interpreted as belonging to the executable name, so that the kernel tries to run a program named perl5\r and fails.
Deleting the trailing \r on this line should fix the problem.
Alternatively, it may be that the perl5 executable either does not exist at the given path, or exists but lacks the execute permission bit. If you have this executable living somewhere else in the filesystem, update the path on the first line of the script to point to it. To fix the latter problem, run
chmod +x /usr/local/bin/perl5
You will need to be root to do this.
Given the output you are showing, you are likely executing "sh cmd.pl". In turn, sh is trying to execute the perl interpreter.
Why not spawn "/usr/local/bin/perl5 cmd.pl" directly, this will be more efficient, especially if you are doing that hundreds of time.

How can I install CPAN modules locally without root access (DynaLoader.pm line 229 error)?

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.)