I installed perl 5.14 version just before, when I executed script display errors perl58.dll missing. How can solve the problem..
how can I solve this problem?
It sounds to me that the thing you're describing as a 'perl script' is actually an executable built from a perl script using ActiveState's perlapp with the --dependent flag. By default, perlapp executables are self contained, but the perl{version number here}.dll can be left out to save space.
Possible courses of action (roughly in order of ease + sanity):
Get the original source from the guy who wrote it, & just run it.
Get the guy who wrote it to update the perlapp executable to a non-dependent version or a version that runs under your installed version of ActivePerl.
Pony up for ActiveState's 'business' subscription to download & install ActivePerl 5.8 (and no other version) on that machine.
Find a copy of the perl58.dll and place it where windows will find it. (may require subscription, or the guy who built the perlapp may have a copy lying about)
Extract the original script from within the .exe and either build a newer (and non-dependent) perlapp or just run it from the source as Larry intended.
Depending on what options were used to build the perlapp executable you may have the origional source lying about in a temp directory. Otherwise I believe you may be able to open it up with a program that understands .zip files, but I've never tried this.
It is also possible that you've got a directory in your path that contains a v5.8 perl.exe but not it's accompanying .dll and that you've asked your newly installed v5.14 perl not to place its directories at the beginning of your path. I don't expect this is the case.
Related
I have installed a perl module, say XYZ then a folder is created that contains many .pm files. I copied the folder and put it in any other system where XYZ is not installed. So, I'm able to use methods of XYZ module in both system. I mean, I'm unable to find out the difference between these method, but I think there must be some. What I know is, when we install a perl module then dependencies also gets installed. Am I right? Can anyone mention other difference between two, if any?
A few off the top of my head:
In case of an XS module, the code is compiled for the local platform.
Installing a module via cpan usually runs the test suite so if there is any other reason beyond dependencies why it wouldn't work, you're told so (I guess that's very rare though)
Regular installation automatically goes to a directory where your perl can find modules.
Of course you can take care of all these yourself. These days chances are pretty good you're running either Linux or Windows on something x86-ish and as long as you only copy Linux to Linux and Windows to Windows, and to the same place as on the source system, you'll be fine. Basically that's what binary Linux distributions and ActivePerl packages do, too, and it may make sense e.g. if you want to avoid installing a whole bunch of compile-time dependencies on all target systems. Just make sure you don't get yourself into a mess by writing to system directories (e.g. /usr/share/perl5) that are supposed to be managed by your system's package manager.
I try to build a Perl distribution for a home-made module, from the Module::Starter base. Every test pass on my machine, but when I upload it to CPAN to get some more universal tests from cpantesters.org, some test failed on other architectures or OS, but I can't understand why. I can see in test reports that some of my prerequisites are not installed before testing but I would like it to.
I've tried to list these dependencies into the Makefile.PL PREREQ_PM hash and then in the TEST_REQUIRES hash, but it didn't changed a lot of results.
Then, when I've removed the dependencies from my local machine and tried to install my module using Cpanm, it downloads dependencies first, test passed and install has been a success.
This is my first try for a module, so I think I am missing something, maybe I am too used of the Cpanm magic. Thanks for any help.
The problem is something different. Andreas' smoker very probably built the dependency App::Ack (which looks in the fail reports like being absent) successfully. But here come at least two problems:
When a distribution gets tested, then its dependencies may or may not be installed already. However, it's guaranteed that all dependent modules are made available through the PERL5LIB environment variable, so make test usually works (To be more specific, if the install Module command is used in the CPAN shell, then all dependencies are installed immediately. If the test Module command is used, then dependencies are only built, but not installed. The CPAN user can do the installation later using install_tested). So it may be that App::Ack is not installed here, just built. Especially this means that the ack script is not installed in the final location.
Even if it is installed, many smoke testers or users who have multiple perls installed in parallel use a non-standard directory for this perl. So ack wouldn't be installed in /usr/bin or /usr/local/bin, but in the bin directory belonging to this perl. This directory may or may not be in the user's PATH at all. So you cannot assume that can_run("ack") works here. A workaround here is to add $Config{scriptdir} temporarily to $ENV{PATH}. Another solution would be to use the App module instead of the script, if it's possible. Unfortunately it looks like ack can only be called as a script.
If you look at a sample fail report, then you can see that App::Ack was installed (it appears in the PREREQUISITES section both under requires and build_requires, you can also see which App::Ack version is installed in the "HAVE" column). You can also see the user's PATH (in the ENVIRONMENT section). And you may guess about the scriptdir for this perl, it's usually the same directory where the perl binary itself is installed, and the path to current perl is visible in $^X (under "Perl special variables").
If you want to reproduce the behavior, then you need to deinstall ack from your machine, build a custom perl using ./configure.gnu --prefix=/path/to/custom/perl-5.X.Y, and use this perl for tests.
I was using PAR::Packer and this question popped up in my mind. How does PAR::Packer work in Perl? Does it actually compile the Perl script to .exe like g++ compiles C++ Sources to .exe or does it work like py2exe in Python that packs the interpreter and the script into an .exe?
To make this absolutely clear:
Tools like PAR::Packer do not “compile” your Perl script. They bundle the perl interpreter together with your source files and any required modules into a big fat executable file. When it is run, the original sources are extracted and fed to the enclosed perl.
This works reasonably well, but does not yield a speed improvement (on the contrary…). The only advantage is that you can distribute your programs as a single (albeit quite large) file, without dependencies.
There is a very experimental tool called perlcc that is able to translate some Perl programs to C or a Perl bytecode serialization. As the docs put it:
The code generated in this way is not guaranteed to work. The whole codegen suite (perlcc included) should be considered very experimental. Use for production purposes is strongly discouraged.
This is because the Perl language does not support static compilation. It needs to be able to execute code during parsing for some dynamic features during the same session where the main execution phase takes place.
There are other, commercial tools, that usually fall in the same category as PAR::Packer (creating fat executables).
Summary: If you want a single executable, use PAR::Packer. If you want speed, inline some C (or use XS). There is no tool that can compile all Perl scripts to machine code.
I was using PAR::Packer and this question popped up in my mind. How
does PAR::Packer work in Perl?
Does it actually compile the Perl
script to .exe like g++ compiles C++ Sources to .exe
no pp and perl2exe doesn't. (though pp is free).
but it looks like perlcc does
or does it work
like py2exe in Python that packs the interpreter and the script into
an .exe?
pp and perl2exe, yes
As an example- sendemail.exe that looks like something done in PAR Packer or Perl2exe
It packs the interpreter into the exe.
You can open sendemail.exe in 7-zip! There are some folders there but one can't really see it actual files.
I suppose it's some form of self extracting executable, but, that executes code.
You can monitor it with process monitor, and you see.
Or with, process explorer and see if it uses any dll from the temp directory that it creates..
It creates a temp directory e.g.
C:\Users\user\AppData\Local\Temp\pdk-user <--- Win7
or
C:\Documents and Settings\user\Local Settings\Temp\pdk-user <-- WinXP
The temporary directory it creates contains a bunch of strange named DLLs and a DLL called perl58.dll which is no doubt, the perl interpreter
I'm sure at one point I saw it had a dll there with a normal name. SSLEAY32.DLL and interestingly when I ran the pl file it used a dll with a similar name from my c:\perl64 directory. So the EXE looks like a bit of a hack really. It's more reliable to run the pl file directly.
DIR /s/b within that directory, shows-
178c2b604baa8a7f1ebc80539f378bff.dll
1823e8f62785746fd29cf0b06c636600.dll
465d2954d90fe6225ea61b3907c91da8.dll
6145f78a34d5ced8200800f1455d578a <-- the directory with the perl58. dll
9c50b5816b0e35f047e41f5899721d46.dll
f4e2e0db77ed1e6572c2f490479cd815.dll
f72f556d99dfb6b0c3bb37f123e2ee96.dll
6145f78a34d5ced8200800f1455d578a\perl58.dll
no normal named DLLs showing other than perl58.dll (though I have seen a normal one there in the past).
if you look in process explorer, you see it using perl58.dll and other normal named dlls
If you look at the PAR website, a page describes perl2exe
Perl2Exe is commercial, command-line application that can build
standalone executables from perl sources. It works by creating an
executable that contains
A standalone perl interpreter (that is capable of grokking perl 5.8.x)
Your perl script and All perl modules that are referenced by your perl
script.
pp - PAR Packager provides that same functionality, but is free.
And if you look here
http://www.perlmonks.org/?node_id=237943
...the perl2exe tool is not a way to hide your source code.
Now it's even come to the attention of the security community (reported in bugtraq, for example).
For details, see the report from net-security's page.
Please stop supporting perl2exe. Please use PAR for a complete installation package, or perlcc to simply compile the top-level program.
-- Randal L. Schwartz, Perl hacker
So, PP and perl2exe combine the interpreter into the EXE, And you can get an idea that there's something funny atypical about the EXE when it opens in 7zip!
perlcc compiles properly.
it appears to have been unmaintained for a while http://www.perlmonks.org/?node_id=654568 , people said it was buggy, but some work was done on it as recently as June 2014 http://www.yapcna.org/yn2014/talk/5603 It gets better performance than interpreted perl. (unlike the EXEs that pack an interpreter, which are slower than running a perl script normally).
I want to generate a ER Diagram sort of, of my spatial database i created inside of Postgresql. As i am also new to Postgresql, i am not too sure if the diagramming functionality can be done using whats offered by the PgAdmin (not referring to the Graphical Query Builder). However, it seems to me there is none. I read around that there is a perl based tool called postgresql_autodoc that can run through PostgreSQL system tables and return HTML, Dot, Dia and DocBook XML which describes the database. Now this is not exactly what i wanted but its the closest option i have. So i have successfully installed, ActivePerl 5.8 and DBD-Pg 2.10.0 for Perl 5.8 (DBD PG is a Perl DBI driver for the PostgreSQL database) and i have also downloaded the postgresql_autodoc.pl file. I have also added the path for Perl. But when i try to run the postgresql_autodoc.pl via the command prompt, i was getting this error: Possible Unintended Interpolation of #TEMPLATE in string at C:/Perl/bin/postgresql_autodoc.pl line 1831. Global symbol "#TEMPLATE" requires explicit package name at C:/Perl/bin/postgresql_autodoc.pl line 1831. Execution of C:/Perl/bin/postgresql_autodoc.pl aborted due to compilation errors.
I tried to view the postgresql_autodoc.pl using notepad++ however i have no experience with the perl language and so i cant figure out what is really wrong. All i could do is locate line 1831 but i dont know what i should do to fix this problem.
The postgresql_autodoc.pl file was downloaded from: http://www.rbt.ca/autodoc/
I would appreciate if anyone can help me here!
Thanks in advance
Barbara
That thingy, ##TEMPLATE-DIR##, is a string that is replaced when you build and install the module -- meaning you're not supposed to run it directly from the unpacked archive.
Most Perl modules are installed with a more or less simple three-step installation process, something like perl Makefile.PL ; make ; make install. However, this package is slightly different, you seem only to need make install.
Note that I have no experience with installing Perl modules on Windows with ActiveState. So the above may not work (e.g. if there's no make utility which is usually not part of Perl -- though it might be part of the ActiveState Perl distribution).
But there's a workaround. You can simply do what the install script does and replace the ##TEMPLATE-DIR## string yourself. It can be done easily with any text editor by replacing the two occurrences of ##TEMPLATE-DIR## with the path to where the postgresql_autodoc.pl script has been unpacked to -- meaning it's the path the script will look for the *.tmpl files in.
Note that Windows path names can be written with forward slashes in Perl, meaning C:/Temp/postgresql_autodoc should be OK.
I am trying to set up an application dependant on few Perl modules, but the server I am installing to, does not have Internet connection. I read about offline module installs via ppd files, however I would have to resolve all the dependencies one by one.. All the more tedious considering I don't have direct internet connection.
I am hoping to find a solution, where I install ActivePerl on my PC and install all the libraries that I want and then copy paste the directories to my server. If it is just a matter of fixing some environment variables, that would be fine. Just want to know the definitive list of variables to modify. Not sure whether it is mandatory to install the perl libraries on the computer in which it is intended to run? (One is 32 bit platform and other one is 64 bit, but the server is already running various 32 bit applications so I hope it is not a major problem) For best compatibility, I plan to install ActivePerl on both the systems and merge the library directories to be identical.
The answer was on Perl FAQ, my bad didn't go through it properly.
I copied the perl binary from one machine to another, but scripts don't work.
That's probably because you forgot libraries, or library paths differ.
You really should build the whole distribution on the machine it will
eventually live on, and then type "make install". Most other approaches
are doomed to failure.
One simple way to check that things are in the right place is to print
out the hard-coded #INC that perl looks through for libraries:
% perl -le 'print for #INC'
If this command lists any paths that don't exist on your system, then
you may need to move the appropriate libraries to these locations, or
create symbolic links, aliases, or shortcuts appropriately. #INC is also
printed as part of the output of
% perl -V
You might also want to check out "How do I keep my own module/library
directory?" in perlfaq8.
From this link
Occasionally, you will not be able to
use any of the methods to install
modules. This may be the case if you
are a particularly under-privileged
user - perhaps you are renting web
space on a server, where you are not
given rights to do anything.
It is possible, for some modules, to
install the module without compiling
anything, and so you can just drop the
file in place and have it work.
Without going into a lot of the
detail, some Perl modules contain a
portion written in some other language
(such as C or C++) and some are
written in just in Perl. It is the
latter type that this method will work
for. How will you know? Well, if there
are no files called something.c and
something.h in the package, chances
are that it is a module that contains
only Perl code.
In these cases, you can just unpack
the file, and then copy just the *.pm
files to a directory from which you
will run the modules. Two examples of
this should suffice to illustrate how
this is done.
IniConf.pm is a wonderful little
module that allows you to read
configuration information out of a
.ini-style config file. IniConf.pm is
written only in Perl, and has no C
portion. When you unpack the .tar.gz
file that you got from CPAN, you will
find several files in there, and one
of them is called IniConf.pm. This is
the only file that you are actually
interested in. Copy that file to the
directory where you have the Perl
programs that will be using this
module. You can then use the module as
you would if it was installed
``correctly,'' with just the line:
use IniConf;
Time::CTime is another very handy
module that lets you print times in
any format that strikes your fancy. It
is written just in Perl, without a C
component. You will install it just
the same way as you did with IniConf,
except that the file, called CTime.pm,
must be placed in a subdirectory
called Time. The colons, as well as
indicating an organization of modules,
also indicates a directory structure
on your file system.