I am trying to write perl program to make changes in Perforce.
When I run Perforce commands using P4 from the command line, those work fine but when I write "Use P4" in a perl program, it is not able to identify the P4 class.
Is there any configuration I might be missing?
P.S> -Since, it is working fine from a command line, I am assuming that my path is set correctly.
This is the error which I am getting:
Can't locate object method "new" via package "P4" (perhaps you forgot to load "P4"?) at perlP4.pl line 5.
This is my program:
use strict;
push ( #INC,"C:\Program Files\Perforce");
use lib "C:\Program Files\Perforce";
use P4; # a p4perl module
my $p4 = new P4;
Any help would be appreciated.
P4 module is stored in a file P4.pm. Try to find this module in your system to see it is installed or not.
If it is not installed, then please install it first.
http://www.perforce.com/perforce/doc.current/manuals/p4script/02_perl.html
I haven't used Perforce in a while, so I maybe out of date here:
The P4 module requires the Perforce C++ API library to be used, and there is quite a bit of compiled C programming with the P4 module. With Windows, much of this is already compiled (and I see you're using Windows).
Read the installation directions very carefully. Make sure you have the API libraries installed as well as the P4 module (and all of its sub-modules) installed. Since use P4; itself doesn't throw an error, I am assuming that the Perl portion of the P4 module is installed. The problem is communicating with the P4 C++ API.
The sub new subroutine isn't in the P4.pm module, but is part of the P4.xs XS package. If you have P4.pm installed, but you don't have the API setup correctly, you will get the error you're getting.
On your command prompt run the following:
perl -MP4 -e "print P4::Identify()"
If you have not installed the p4perl module you will see:
Can't locate P4.pm in #INC (#INC contains: /etc/perl /usr/local/lib/perl/....
.... (snip) ....
BEGIN failed--compilation aborted.
Related
I have a Perl script which uses the module Net::SSH::Any. Since it does not belong to the “default” Perl installation, I have to use the use lib functionality to include it in my script.
Now, I have the directory c:\lib\net\ssh\any\ on my drive and I specify this: use lib c:/lib; at the beginning of my script.
It “works”: it didn’t say that the module is missing but it says that it couldn’t locate auto/Net/SSH2/autosplit.ix and at the end no backend available at...
When I add the auto directory (containing the correct structure) in the c:\lib\ directory and launch the script, I get this error:
No backend available at...
Which is an internal error of Net::SSH::Any mentioning it could not access the backend directory (which is already included :/)
Does anyone know how to solve something like that? I hope I was clear enough.
You need to use Local::Lib.
This will let you install and load a whole bunch of libraries and their dependencies in an alternate location. I use cpanm to manage my modules and a command something like this (which I put in a wrapper script).
cpanm -L $cpandir $M --no-skip-installed
Where $cpandir is your locallibdir and $M is the module you are trying to install.
Then in your code you would specify
use local::lib '~/foo';
However, I recommend setting a PERL5LIB environment variable, which will append your custom location to #INC and make the extra use local::lib line unnecessary. You would typically edit .bashrc or .profile in your home directory with a line like:
export PERL5LIB=/home/myusername/mymods/
The issue was caused by the fact that the module was downloaded and installed on a 32bits windows but I tried to run it on a perl 64bits installation! So the Net::SSH2 required module couldn't be executed properly.
To resume:
-How to detect the issue: by executing this command: (thanks to Salva)
"perl -Ic:\lib -MNet::SSH2 -e1"
-Modules definitions in my script:
use lib 'c:\lib';
I have been using telnet to issue test commands to my Jabberd2 server. It is a clunky method, so I downloaded the sendxmpp package included with my build of Cygwin. When I issue the command sendxmpp -h I get the following error(minus the #INC path dump): can't locate Authen/SASL.pm in #INC BEGIN failed--compilation aborted at /usr/bin/sendxmpp line 21.
I think the problem is ldap related, however I have installed all of the perl and ldap modules available.
Does anyone know how to fix this error?
Are there additional configuration steps needed to get ldap working
with perl in the Cygwin environment?
Is there a better way to issue xmpp commands to Jabberd from the
command line?
Looks like you're missing the Authen::SASL module. If it's not part of the sendxmpp package, try installing it with cpan -i Authen::SASL. If it IS available, make sure sendxmpp (which may very well be a perl script) finds it, by modifying the inc/lib directory. If Authen::SASL is supposed to be installed and available systemwide, try executing perl -MAuthen::SASL. If that triggers an error, perl can't find it. If it just "hangs" there (waiting for input), perl did find the module, and sendxmpp should work.
I have installed PAR from CPAN. Now, how do you use it? It gives usage example as:
% pp -o hello hello.pl
How do you use this on Windows? pp gives "command not found".
I am new to perl. Only thing I need is to run a module.
pp isn't a module, it is an application. You need to figure out where it was installed to (I don't know which perl you are using or how you installed it) and use the full path to it.
You should look in your lib directory to ensure that the pp.pm file exists somewhere. then, you can load it up by typing use Par::pp; at the perl command line (i'm guessing that it is part of PAR based on what i've found, it could be something as simple as use pp; at the command line).
once the module is loaded, it should provide the pp command for you to use.
thanks,
mark
I have multiple versions of Perl installed; each under a different directory. e.g. C:\Perl\5.x.y. I switch between them in a shell by setting PERL5LIB and altering my PATH so that only one version is visible at a time. Normally, this works fine, but when trying to run the version of pp (PAR::Packer) installed under 5.10.1 I have problems loading XS components. parll2nc.exe complains:
This application has failed to start because perl512.dll was not found...
I set PERL_DL_DEBUG and see the following when DynaLoader initializes:
DynaLoader.pm loaded (C:/Perl/5.10.1/site/lib C:/Perl/5.12.1/lib ., \lib)
The stuff before the comma is #INC. The first entry is correct, the second is not. I can't figure out how DynaLoader is getting a 5.12 lib path as running perl directly shows what I would expect:
C:\>perl -e "print join ' ', #INC"
C:/Perl/5.10.1/site/lib C:/Perl/5.10.1/lib .
How is DynaLoader picking up the wrong path and how do I prevent it from doing so?
Similar to the approach I suggested for this question, put a trace on #INC and see when it gets updated.
At the very top of your script, before any other use statements, put:
use Tie::Trace;
BEGIN { Tie::Trace::watch #INC };
Then you will get a warning message when another module edits your #INC array.
I figured it out. The problem is caused by an interaction of several things:
I have *.pl files associated with perl.exe (for the most recent version of Perl installed -- 5.12.1).
I have ".PL" in my PATHEXT environment variable so that I can run Perl scripts without typing the extension. e.g. C:\>foo instead of C:\>foo.pl
My installation of the pp utility does not have a batch file wrapper created with pl2bat. (I'm not sure why.)
The net result is that when I ran pp #myconfig it effectively did this:
C:\Perl\5.12.1\bin\perl.exe C:\Perl\5.10.1\site\bin\pp.pl #myconfig
i.e. it ran the version of pp.pl in my path using the version of perl associated with *.pl files, not the version of perl in my PATH. Thus the mix of libs in #INC between what came from the executable (C:\Perl\5.12.1\lib) and what came from the PERL5LIB environment variable (C:\Perl\5.10.1\site\lib).
The solution is to either run pp as perl pp.pl or (better, because you don't have to remember anything) to create a batch wrapper. Assuming that .BAT is in PATHEXT before .PL, when you type pp Windows will run pp.bat instead of pp.pl, and pp.bat invokes perl (using the version in your path).
sigh
I'm new to Perl. I get the following error when I run a script:
Can't locate URI.pm in #INC (#INC contains: /usr/local/packages/perl_remote/5.6.1/lib/5.6.1/i86pc-solaris /usr/local/packages/perl_remote/5.6.1/lib/5.6.1 /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/i86pc-solaris /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1 /usr/local/packages/perl_remote/5.6.1/lib/site_perl .) at (eval 2) line 3.
Compilation failed in require at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/HTTP/Request.pm line 3.
Compilation failed in require at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/UserAgent.pm line 10.
BEGIN failed--compilation aborted at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/UserAgent.pm line 10.
Compilation failed in require at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/Simple.pm line 26.
BEGIN failed--compilation aborted at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/Simple.pm line 26.
Compilation failed in require at txotf_0_install.pl line 35.
BEGIN failed--compilation aborted at txotf_0_install.pl line 35.
What could be the possible reasons of this and how do I get the script to work. Any help will be appreciated.
Possibly you do not have URI installed. It might not be saved anywhere on your machine, or it might be "installed" in a location.
If it's just not installed, then you need to install it from CPAN.
If you have it saved to your machine, you just need to let the system know where to get it.
If you have to install it from CPAN, you likely need administrator privileges to put it in the listed directories. But CPAN will allow you to install it to a user directory, so you can still install it.
So if you can't install the module in the directories listed in #INC, then there are the various ways.
Perl 5 reads a environment variable called PERL5LIB. Any directory in that "array" will be prepended to #INC. So anything in the directory structure of $ENV{PERL5LIB} will be preferred to any system directory. (see here)
Another way you can do this is per script. The use lib pragma also inserts specified directories into #INC. (see lib)
use lib '/path/to/URI/module';
use URI;
The final way, you can do it per run. You can run perl with the -I switch on the command line perl -I/path/to/URI/module -e 1 (see perlrun)
The nonstandard paths in #INC (e.g. /usr/local/packages, perl_remote etc) indicate to me that this is a custom perl installed for a specific purpose probably with reduced functionality to prevent mischief.
Ask the sysadmin.
The array #INC contains the list of places to look for Perl scripts to be evaluated. Your script will not run because it is not in the #INC list. Either:
Put the script in one of the #INC locations; or
Add the location of the file to the $PATH environmental variable; or
Specify the full path of the script when you are calling it.
This is not to say that any of the other answers aren't all good advice (they very likely address your issue), but I ran into a similar issue which had me puzzled for a couple hours. While I'm not sure this addresses the OP's problem, perhaps someone stumbling across this in the future will save themselves some time troubleshooting...
I found on a new CentOS server that despite #INC reporting the path to my custom libraries included and despite all file and directory permissions being set correctly mod_perl was still bailing out with a message that it "Can't locate" the modules in question. This was doubly puzzling because similar scripts with the same "use lib" statement that Apache's PerlRequire was using were able to run without issue.
The culprit turned out to be SELinux, and disabling it took care of this immediately. More details on the /var/log/messages info that led me to this as well as other general gripes can be found here.
In my case I just copied the perl folder to another machine and added path to bin folder to PATH environment variable. In order to fix the issue, I had to run the proper installation of ActivePerl which at the end setup all the environment properly for perl.