Installing with the cpan cli tool modules - they are not found at script execution time basically as part of the #INC directories. I am using cygwin.
/home/myuser/.local/share/.cpan/build/Email-Sender-1.300031-0/lib/Email/Sender/Simple.pm
/home/myuser/.local/share/.cpan/build/Email-Simple-2.216-0/lib/Email/Simple.pm
I could now reference each single lib directory (they differ with each module installation) using the PERL5LIB Variable which is dull and boring. Am I doing something wrong? I want to install Perl Modules with cpan and use them afterwards without care where they are located...
All the module installation failed because the 'make' utility was not installed.
Now the cpan modules get installed and can be used within my scripts.
I'm trying to install perl module. But, I have this error:
"Can't find C:\Strawberry\perl\bin\cpan.bat on PATH, '.' not in PATH".
And, when I use cpan from strawberry directory and try to install module, perl can't find it.
Please confirm these process done by you in your machine.
Go the System properties and Click ENVIRONMENT Variables
Add your Strawberry perl path in USER variables C:\Strawberry\perl\bin
Add your Strawberry perl path in SYSTEM variables C:\Strawberry\perl\bin
I hope this is clear for you.
I have already installed Perl and libcurl using Cygwin's package manager. Now, I'm trying to install WWW::Curl. I have to specify the cURL include directory in WWW::Curl's Makefile.PL, but I have no idea where to look for this. Thanks for your time.
It will try to guess automatically. If it does not work, see the README.
P.S. LWP is more convenient to use.
edit: Using your package managers own packages is often preferred when using your system perl, cygwin has a package for perl-WWW-Curl, install this package rather than building your own.
Most likely I think you are missing the libcurl-devel package. Although you mention that libcurl is installed, please ensure that libcurl-devel is installed via the cygwin package management application, and try again if required.
WWW:Curl will search for the correct include path, looking for curl/curl.h, if it cannot find the file then it might be looking in the wrong places, you'll have to do a manual install:
download and unpack the package from cpan
read the included README file to understand this process
search your cygwin installation for a file called curl/curl.h note the directory that it is in.
modify the Makefile.PL so that #includes has the directory noted above included.
run perl Makefile.PL
run make && make install
This process is essentially the same problem as the process for a native Win32/strawberry perl install, in that it doesnt know where libcurl is located. you can check the README.Win32 file for similar instructions.
The libcurl-devel package installs the curl/curl.h file to usr/include/ which is a path that is already searched by Makefile.PL.
To however you say you have no idea where to look, locate the curl.h you can do the following:
find / -name curl.h
But be warned this could take a long time, you could try specific locations such as /usr
find /usr -name curl.h
Or even better you can look at the package contents to find the file location:
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86%2Flibcurl-devel%2Flibcurl-devel-7.41.0-1&grep=libcurl
To echo Alexandr's answer, LWP is more convenient to use cross platform, while covering the same features, it can also do a lot more.
I downloaded the 5.12.3 installer to upgrade my 5.12.1 installation. After installing 5.12.3, my previously installed cpan modules are gone. Is this expected behavior? Should I be backing up my library before upgrading to prevent this?
I would claim that this should not be expected behavior.
The site directories are not part of the standard distribution and should not be touched by the distribution. Heck, it's even why the site directories even exist. Otherwise, why not simply download all of the modules to the same directory? Why make a distinction between the standard Perl modules and the modules you download from CPAN?
I too found this out the hard way when my personal modules -- modules that are not part of CPAN -- were blown away by my upgrade of Strawberry Perl. ActivePerl does it right -- not only not touching the site directory, but also adds in the Perl version to the standard module directory and the site directory.
It is expected behavior. Next time you can use "autobundle" feature of CPAN client, it will create list/bundle of modules to reinstall using CPAN client in new version.
I need to run Perl applications I develop on cygwin Windows on HP unix / Solaris hosts. I am not a superuser on the unix machines and I can't touch the default Perl module location nor can I install modules to the default Perl module location. Also the unix installation lacks most basic modules and I can't change that.
For example, I have a Perl application that needs Expect which has native C compiled parts to it. How would I roll out this application to unix with its required dependencies without having to install anything else on that box?
Is there way to build the entire Perl application under Cygwin Windows and then just roll out one executable to unix and run it from my home directory there?
EDIT addition based on answers so far:
Thanks in particular to brian, the local LIB dir solution seems to work in case of native Perl, but in case of Perl module needing C components, cross platform compiling, ie compiling on cygwin to run on Solaris, is not really possible as I feared.
However would having an other linux installation help, i.e. would this be possible easier between different flavors of Unix like package Perl on linux and then deploy to Solaris/HP? And what about something like lcc ?
Also I'd still like to hear little more if somebody has rolled out a native Perl package on Windows that includes all dependencies for a complicated Perl app that can then be moved to unix as just one file? (I do now understand that it won't work in case native C code is included like in in Expect.pm, but what about in case of app only using pure perl modules?)
Basically for many reasons I am trying to minimize time I need to spend being logged into these "production" unix hosts and do as much as possible locally beforehand.
Added a new cross-compile question, since I felt I was maybe veering too far from the original perl question.
EDIT -- Par looks promising for pure Perl, although same deal, it doesn't look to solve the cross platform compile problem for native extensions
In this case, I'd consider delivering a complete application complete with its own Perl. You get to choose any version you like and any modules you like. Compile everything, organize everything into a directory, then tar the result. To deploy, copy the file and untar. Use the advice that others have already noted about library search paths, etc. In essence, your application gets its own stack.
Now, the trick there is the cross compilation. Why are you developing on Cygwin? Is that a target too? Is there a reason you don't have an HP/UX or Solaris development machine? What architecture are you targeting (RISC, SPARC, Intel, etc). If you can't get hardware to run those, get some virtual machines for your targets and develop there.
Aside from that, you can install modules anywhere you have permissions. See perlfaq8:
How do I keep my own module/library directory?
How do I add the directory my program lives in to the module/library search path?
How do I add a directory to my include path (#INC) at runtime?
I haven't tried this particular feature, but perl2exe says it supports cross platform builds.
Compiling a Perl script with all its dependencies on Windows with Cygwin and running it Solaris is just not going to work.
Now the question is: do you have access to a compiler on that Solaris computer? It's not because you do not have root access that you cannot compile and install Perl modules in your home directory by using:
perl Makefile.PL PREFIX=$HOME
If you have CPAN available on your Solaris system you can set the prefix in the CPAN shell this way:
start the shell perl -MCPAN -e shell;
change the prefix with conf makepl_arg PREFIX=/path/to/your/home/directory
For your script to run, you can either start perl with the -I $HOME command-line switch, e.g.:
perl -I $HOME script.pl
Your other option would be to place this at the begining of your script
use lib $ENV{'HOME'};
Set your environment variable PERLLIB to your personnal Perl lib directory or use the -I command line switch to Perl to indicate it.
If you have access to the HP-UX machine you can compile Expect there and install it in your directory. But cross compilation from Windows to HP-UX is probably much more difficult. You would have to build a GCC cross compiler.
If you have a compiler on each of your systems (and some other tools needed by configure like grep), you should not only be able to compile modules, but you should also be able to build your own perl executables.
You'll want local::lib. Once you've done that, the pure Perl modules should work cross platform, but you'll have to identify and reinstall the compiled modules on the foreign platform. Do the initial install on a real unix, cpan on cygwin is slow.
I've run across this several times on my work systems. We have a base install of Perl 5.8 and I don't have the ability to add modules. Here's the solution I use:
Create a folder called 'lib' in your
project root (ex:
~/projects/MyProject/lib)
Any
modules you download from CPAN
should have a Makefile as well as a
directory called "lib". Copy the contents of the lib folder into your newly created lib folder. Some modules may only contain a single .pm file, and no lib structure. Just copy the .pm file.
Your code should do the following: first, use any modules that have been installed normally, then unshift your #INC environment variable to use your local libraries:
# Declare Includes --------------------------------------------------------------------------------
use Getopt::Long;
use vars qw($VERSION);
use DirHandle;
use FileHandle;
# Force perl to use our local 'lib' directory for imported modules, this allows us to
# use modules without having to install them in th emain perl assembly. However, this
#also prevents these modules from being used in other projects.
BEGIN { unshift #INC, "lib"; }
use Error qw(:try);
use SOAP::Transport::HTTP;
#use LWP::Protocol::https;
use XML::Simple;
use XML::Writer;
use XML::Writer::String;
The caveat to this method is that some Perl modules don't use the 'lib' method or have additional dependencies. If you run into problems, examine the Makefile.PL for the module and see what it's doing.