Re: Help with pp - Perl Packer
by marto (Cardinal) on Jan 29, 2015 at 16:20 UTC
|
Did you run the exe on the same system you use to create it? The reason I ask is that this (: is not an identifier) looks like a problem I'd expect to see from a shell/environment issue, rather than perl. Without knowing more about the code you are packaging I'm having a hard time thinking about what could cause this.
As a side note I'd suggest running pp with the -x option to run your code and check for additional run time dependencies. You can unpack the 'executable' you've created (just unzip it somewhere) and see exactly what has been packaged.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Thanks for the swift response. when you say shell/environment issue, is that when running the executable or creating it? the systems are the same as far as I am aware. I would happily post the code up, although it is rather large, and editing it to make it not work specific/anonomous may take longer than it did to write the thing i'm afraid.
Is the fact the executable does run without error highlight that perhaps the perl is ok, and as you say more of a systems issue? one thing I did try in order to eliminate some possibilites is to create a .exe to run as an icon from a windows environment but i'm guessing i'm getting way ahead of myself there as this didn't get close to even working....?
| [reply] [Watch: Dir/Any] |
|
I mean the environment running the executable you created which results in the error. Are you working with environment variables within the code? Posting a short example which recreates the issue would be advantageous.
"Is the fact the executable does run without error highlight that perhaps the perl is ok, and as you say more of a systems issue?"
This statement has confused me. I thought your report was that the executable did spit out an error at the prompt?
"one thing I did try in order to eliminate some possibilites is to create a .exe to run as an icon from a windows environment"
I think your efforts would be better spent isolating the problem in the current environment.
| [reply] [Watch: Dir/Any] |
|
|
|
Re: Help with pp - Perl Packer
by dasgar (Priest) on Jan 29, 2015 at 16:23 UTC
|
I'd recommend looking over the documentation for pp to get familiar with the various options.
It would be more helpful for others to understand your problem better if you included more details on what didn't work as well as some information of the code itself.
Based on what you say that you used (pp -o file.out file.pl), I think that what happened is that the pp utility didn't pick up all of the needed modules (and/or possibly needed libraries). I'd recommend using the -c and -x options (NOTE: those are lowercase letters - see the documentation of pp for more details). You may need to even use other options to manually include needed modules and/or libraries.
| [reply] [Watch: Dir/Any] [d/l] |
|
Thank you dasgar. I did wonder whether other options where a possibility. I had a good read of the man pp page in order to figure out possible necessary options, but from reading, it started to talk about PAR aswell, and i'm not entirley sure on the difference of a .PAR or .out?
My understanding was that using pp in its naked form should include all libraries and modules etc. by smart reading the 'includes/use' of the script, and in honesty, the only module I see being a problem is the Digest::MD5 qw(md5_hex) which I use for simple encryption (just keeps the QA team away from the gears and cogs ;) )
| [reply] [Watch: Dir/Any] |
|
use strict;
use warnings;
use Digest::MD5;
Let's say that was in a file named script.pl. If we run pp -o program.exe script.pl, pp would package in the Digest::MD5 module. But if you look at the Digest::MD5 module, it uses the Digest::Base module. Since the code above does not explicitly list Digest::Base, pp doesn't know that it needs to grab it.
That's where the -x and -c options come into play. They tell pp to run the script to pickup any additional run-time dependencies. In this case, by running pp -c -x -o program.exe script.pl, pp will discover that Digest::MD5 needs Digest::Base and will then add in Digest::Base. There are times pp will still miss required modules. In those cases, you can use the -M option to explicitly add in those modules.
This is just a super simple example that I came up with to help explain what the -c and -x options do. Others could perhaps give a better and/or more detailed explanation, but I'm hoping this helps you better understand those two options do.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Re: Help with pp - Perl Packer
by RonW (Parson) on Jan 29, 2015 at 21:46 UTC
|
How different are the "model office" PCs from your PC?
Usually a missing module or library will result in a message stating that the module or library can't be found.
The message you are seeing, : is not an identifier seems to me more likely to be caused by a configuration or other environmental difference between your PC and the target PCs.
| [reply] [Watch: Dir/Any] [d/l] |
|
Thanks for your response RonW. I initially came across the oringinal problem of the script not working in the model office when trying to run the script it complained about missing modules regarding the Digest::MD5 module. That lead me to look into this executable arrangement whereby the necessary modules for the script to run correctly would be packaged within the executable.
The general consensus seems to not be with the perl script itself now, as that runs a.Correctly on my original machine, b.Correctly on the model office machines IF i remove the module dependencey c.Runs as an executable BUT incorrectly displayed on both machines.
When it comes to 'systems' and 'environment' settings i'm a complete beginner, so others are saying that the issue may lye there, however I would have no way of knowing what would cause that at this juncture, but I am still happily digging away at this issue, with all the helpful suggestions from helpful monks such as yourself and others.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Re: Help with pp - Perl Packer
by RonW (Parson) on Jan 30, 2015 at 18:48 UTC
|
There is another possibility, since the office PCs do have Perl. Through the use of use lib, a Perl program can reference additional modules stored in an alternative location on the office PCs.
(You don't say what OS your PCs are running, but this works on any OS that Perl runs on.)
#!perl
use warnings;
use strict;
use lib qw( C:/OurPerlMods );
use NonCoreMod; # because of 'use lib' above, will find in C:/OurPerlM
+ods
Where you put the "alternative" library of modules isn't important. One possibility would be to a create a zip file with your program and the extra modules it needs. Then users would unzip it to where ever you tell them to and could run the program.
If your PCs are running MS Windows, you could create an installer using, for example, NSIS, which is an open source installer builder for MS Windows. | [reply] [Watch: Dir/Any] [d/l] [select] |
|
Ah, now this is interesting. I spent some time with this problem after work on Friday, and I seemed to have taken a step forward - I now have an executable, that I unzipped to see what was inside. It does indeed contain the modules that are need for that code. So I do believe that what I actually have is a viable working executable.
However, this still leaves me puzzled as to why it displays incorrectly, still showing the :not an identifier output, upon startup and during the program? this may be unrelated to the executable creation, so perhaps this is now a different topic to discuss? If so, can anybody (more experienced in the monestary) kindly let me know if I should continue here, or start a new thread?
Many thanks as always
| [reply] [Watch: Dir/Any] |