I have just installed the package in my system using the instructions described in the question "How to install .pm to run the perl script"
Now, I am trying to run the Perl script But I still see the following error:
Win32::OLE operating in debugging mode: _Unique => 1
at C:/Dwimperl/perl/site/lib/Win32/OLE/Lite.pm line 30
require Win32/OLE/Lite.pm called at C:/Dwimperl/perl/site/lib/Win32/OLE.pm line 48
require Win32/OLE.pm called at C:\Users\c_desaik\Desktop\pwrdb\offtarget\pwrdb.pl line 37
main::BEGIN() called at C:/Dwimperl/perl/site/lib/Win32/OLE/Lite.pm line 0
eval {...} called at C:/Dwimperl/perl/site/lib/Win32/OLE/Lite.pm line 0
main::(C:\Users\c_desaik\Desktop\pwrdb\offtarget\pwrdb.pl:53):
53: my $prod_id = "QPSTAtmnServer.Application";
DB<1>
I can actually see the OLE.PM file at the location C:/Dwimperl/perl/site/lib/Win32/OLE but still it is throwing an error.
I did not copy the module, I installed it using CPAN.
I am confused because there are two locations where I see an OLE folder
C:\strawberry\perl\site\lib
C:/Dwimperl/perl/site/lib/Win32/OLE
Normally, when I install something, it has only one root directory. I am not sure why Perl is operated from two of those.
"Win32::OLE operating in debugging mode" is not an error. It's a warning that's issued when a script using Win32::OLE is run from the debugger. Everything is functioning as it should.
It looks like you have both DWIM Perl and Strawberry Perl installed on the same Windows machine. Unless you need to use both simultaneously, then you should uninstall the one you aren't using.
To get things working again you may need to uninstall both versions of Perl and reinstall your preferred brand.
Related
hi am trying to install perl module from cpan in my windows machine am getting below error after hitting two times yes .
Checking if your kit is complete...
Warning: the following files are missing in your kit:
README
Please inform the author.
Writing Makefile for Digest::Perl::MD5
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running make for D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
Is already unwrapped into directory C:\Perl\cpan\build\Spreadsheet-ParseExcel
0.65
CPAN.pm: Going to build D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
>perl exceltoxml.pl
Can't locate Spreadsheet/ParseExcel.pm in #INC (#INC contains: C:/Perl/site/lib
C:/Perl/lib .) at exceltoxml.pl line 4.
BEGIN failed--compilation aborted at exceltoxml.pl line 4.
I have tried 5 times.
nmake' is not recognized as an internal or external command
Sinan Ünür is right. The error message is that you don't have nmake installed. This means you are attempting to compile code (probably C code) and there's no C compiler or Make program.
A while ago, I would tell people that ActiveState doesn't fully support cpan because it can't compile code. ActiveState uses it's own pre-compiled packages available via the Perl Package Manager (PPM) which can be used from the command line or from a GUI interface. If a package isn't available via the PPM and it requires compilation, you were just out of luck. I would usually recommend Strawberry Perl instead of ActivePerl for this very reason. Strawberry Perl comes with the complete MinGW environment needed for those compilable CPAN modules.
However, about a half a dozen years ago, ActiveState put together an installable PPM package for the MinGW environment. Once this is installed, ActivePerl can use CPAN.
So you have two solutions:
Install this PPM package as Sinan Ünür mentioned in his answer. Then, try Spreadsheet::ParseExcel again.
Install Strawberry Perl instead of ActiveState's Perl. Strawberry Perl seems to be more compatible with the version of Perl found on Unix/Mac/Linux systems. Then try installing the Spreadsheet::ParseExcel package.
Okay, three solutions: Install Cygwin which will give you the complete Linux Environment on your Windows machine. It can take about two hours to install, but it comes with all of the GNU utilities you've known and love, most other Unix/Linux utilities, and the BASH shell.
It's what a lot of Linux/Unix homeboys use when they get sick of that ol' C:\> prompt. Cygwin comes with the latest version of Perl and works with every single CPAN package I've tried. There are a few minor issues (Like Termcaps) where things don't quite work the way they're suppose to, but I'm generally happy with it. It even comes with X11 and allows you to run XWindow apps, and even use XWindow apps across systems -- just like a REAL operating system does!
There maybe a few instances where CPAN modules may still have issues on Windows. One has to do with archiving and unarchiving modules and the missing libz library. However, installing this MinGW package (or using Strawberry Perl or Cygwin) will solve about 95% of the cpan installation issues.
I have tried 5 times.
Computers are deterministic things. That means, unless you change the conditions under which a program runs, it will always do the same thing (except, maybe, if there is a solar flare or an EMP).
So, there is no difference between issuing the same command once versus five times. If it failed the first time, ceteris paribus, it fill fail all five times.
That said, it looks like you installed ActiveState Perl, but did not install the MinGW package which provides the gcc & dmake based build tools.
So,
C:\>ppm install MinGW
and then try to install packages.
You also have the option of building your own perl using the Community Edition of Microsoft Visual Studio 2013 tools, or any other supported compiler.
I'm running 32-bit Windows 7 Starter on a cheap netbook. I used to do most of my experimental coding in ActiveState Perl but switched to node.js and stopped using Perl for some time.
I had kept my Perl up to date despite not using it so had the latest version, 5.15.3 Build 1604.
Today I found something I wanted try out in Perl but ran into some problems I'd never seen before.
The perl -V command in the console would lock up without outputting anything.
I uninstalled Perl, reinstalled, did a Windows update, and rebooted my machine but now I get a system error dialog:
The dialog is followed by this error in the console:
Can't load 'C:/Perl/site/lib/auto/Win32/Win32.dll' for module Win32: load_file:The specified module could not be found at C:/Perl/lib/DynaLoader.pm line 191.
at C:/Perl/lib/ActivePerl/Config.pm line 405.
Simple things work in perl, such as printing a literal string. ActiveState's package manager tool, ppm, seems to work fine.
I tried doing a "repair" on the installation through the control panel, but this changed nothing.
After posting the question I've noticed mentions perl512.dll!
For some reason, even though I had uninstalled and reinstalled Perl 5.15.3 something was tying it to Perl version 5.12.X ...
Since ppm was working I tried ppm upgrade Win32 and got:
Win32 0.49 (have 0.44)
Downloading Win32-0.49...done
Unpacking Win32-0.49...done
Generating HTML for Win32-0.49...done
Updating files in user area...done
2 files deleted
1 file installed
4 files updated
Perl -V now works in the console. I can't say I really understand what was going on though.
I'm working on a fresh Ubuntu vm, I've imported Mojolicious, Mango and MongoDB all through terminal (apt-gets and curls) but when I try and run any project that implements Mango - using command:
morbo project/script/project
It returns the following error:
Couldn't load application from file "project/script/project": "dumper" is not exported by the Mojo::Util module
Can't continue after import errors at /etc/perl/Mango.pm line 10
BEGIN failed--compilation aborted at /etc/perl/Mango.pm line 10.
Compilation failed in require at /home/user/project/script/../lib/project.pm line 3.
BEGIN failed--compilation aborted at /home/user/project/script/../lib/project.pm line 3.
Compilation failed in require at (eval 94) line 1.
The Mojo::Util and Mango.pm are all unedited dependencies as downloaded.
Never had any of these problems getting it to run on windows so I'm a bit lost where to start looking for a solution now.
Does anyone know what might be causing this?
Much the same as with other languages such as python or ruby, using system perl is a bad idea and will cause you headaches down the track. What will also cause you problems (much like this one) is pulling down packages "via curl" and simply unpacking to a directory. You need to install most things properly, and there are tools to manage both of these problems.
For instance, the underlying MongoDB driver module requires a C compiler to build as part of it's install process.
You may have installed that one via apt-get. But it is not recommended.
I would recommend using an "environment based" installation such as plenv or perlbrew in order to "manage" your installed perl installation, and not "mess around" with the system installed perl.
In either case, both will integrate well with the excellent cpanminus module and utility. This allows you to install packages from CPAN in a correct way, so that your application works and you avoid errors.
All options allow methods so you can install the modules locally for your application in this way. plenv may be better for you if you need "per application" separation on the same machine in this way.
Use the correct methods, and you are far less likely to run into problems.
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.
I primarily use Textmate for perl hacking on OSX Snow Leopard. It was all fine till some days ago when I installed Macports (I've heard a rumor that macports installs some version of perl in /opt/local). Now, for any new package that I install from CPAN, and try to use if from Textmate, it gives me an error like this when I hit Cmd+R to run it (I had installed HTML::TreeBuilder from CPAN moments before):
Can't locate HTML/TreeBuilder.pm in #INC (#INC contains: /Applications/TextMate.app/Contents/SharedSupport/Bundles/Perl.tmbundle/Support /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .) at /workspace/PerlScripts/test.pl line 2.
However it runs just fine when I run it from command line. If you will notice, textmate is using Perl version 5.10.0. When I run a "Perl -v" from command line, it shows me the version as 5.12.3 (see a copy paste from terminal below)
This is perl 5, version 12, subversion 3 (v5.12.3) built for darwin-multi-2level
The small perl code that I used is this:
#!/usr/bin/env perl <br/>
use HTML::TreeBuilder; <br/>
print $HTML::TreeBuilder::VERSION."\n";<br/>
print "$INC{'HTML/TreeBuilder.pm'}\n";<br>
Then I ran "which perl" from command line and it returned this:
/opt/local/bin/perl
then I ran "print system("which perl");" from Textmate and it returned
/usr/bin/perl
Now I clearly have two versions of perl sitting in my system. 5.10.0 that Textmate is trying to refer to and which cannot see my CPAN installs. And 5.12.3 that looks to be the default version of perl when I run it from command line and the one which my CPAN installs to. I tried to replace this:
#! /usr/bin/perl -w
with this (had read on google that this will force the system default perl to be picked up in textmate):
#!/usr/bin/env perl
No dice yet. Textmate still gives me the same error as I mentioned at the start of the question. So, is there a way to get it to work with Textmate? And is there a way to make textmate point to version 5.12.3?
You need to set the relevant environment variables for OS X. At the moment you probably have them set just for your shell. These will probably be PATH and PERL5LIB.
mkdir ~/.MacOSX
touch ~/.MacOSX/environment.plist
defaults write ~/.MacOSX/environment VARIABLE_NAME VARIABLE_VALUE
You'll need to log out and back in again to activate it.
Make sure that TextMate has your $PATH variables
in Textmate go to Preferences, then the Advanced Tab.
Under Shell Variables, make sure the path to your preferred perl (and cpan) is there something like:
/opt/local/bin:/opt/local/sbin:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
Your inc path can be gotten from:
perl -e 'print #INC,"\n"'
Or from perl -V.
It is higly probable that you installed HTML::Treebuilder in a version dependent path component, so 5.12 can findit, whereas 5.10 does not.
If this is the case, you may either install the relevant modules with 5.10 OR try some tricks with lib.pm:
use lib qw(/usr/perl/site_perl/5.12);
This kind of things are best left to your package manager though, and I do not advise you do this at home unless you are totally sure of what you are doing, as you might introduce subtle bugs due to version incompatibilities (or it could just blow up, but that's easier) .