Re: Problems running a packaged script.

I got it to work using the -M option of pp as I suggested in my first response. I noticed XML::Parser::Expat was mentioned in the first error you posted from running your script. Adding that module with the -M option fixed the problem.

The pp command that worked was:

pp -o salesforce.exe -M XML::Parser::Expat -l zlib1__.dll -l SSLEAY32_
+_.dll -l LIBEAY32__.dll -l libexpat-1__.dll salesforce.pl
[download]

I ran pp in a normal command prompt and ran the exe in a second one where I cleared the 'path' environment variable so that no Perl libraries or modules would be found. Here is what I get from running the exe:

C:\usr\pm\PAR>salesforce.exe
> ORG_IS_SIGNING_UP: org is currently signing up at WWW/Salesforce.pm 
+line 110.
 <
[download]

The script I packed to salesforce.exe is below for reference.

use strict;
use warnings;
use WWW::Salesforce;

eval { WWW::Salesforce->login( 'username' => 'test','password' => '123
+4' ); }; 
print "> $@ <\n" if $@;
[download]

Comment on Re: Problems running a packaged script. Select or Download Code

Replies are listed 'Best First'.
Re^2: Problems running a packaged script. by vitoco (Hermit) on Feb 08, 2019 at 12:54 UTC
I got this work and explained my conclusions in this post of the thread. The final command line was: `pp -a "C:/strawberry/perl/vendor/lib/Mozilla/CA/cacert.pem;cacert.pem" -l libexpat-1__.dll -l libcrypto-1_1-x64__.dll -l zlib1__.dll -l libssl-1_1-x64__.dll -o prog.exe prog.pl` "-M" was not required, as XML::Parser::Expat was automagically recognized by pp, but its library was not, thus requiring "-l libexpat-1__.dll". I'm not sure if "cacert.pem" file is actually required by my script, and I guess that the use of "SSLeay" or "libssl" DLLs is decided by communication modules at runtime depending on availability.	[reply] [d/l]
Re^3: Problems running a packaged script. by Lotus1 (Vicar) on Feb 08, 2019 at 15:46 UTC
I didn't notice your post saying that you got it working before I posted my sucessful node. I'm glad you got it working and I'm interested to learn more about the -a option you used and how you inspected the contents of the temporary PAR caches. vitoco wrote: The final command line was: `[...]` You seem to be implying it is the only correct way. My approach with -M also works and the -M clause is required for my approach. vitoco wrote: "-M" was not required, as XML::Parser::Expat was automagically recognized by pp, but its library was not, thus requiring "-l libexpat-1__.dll". I tried -M with the Expat module and without the Expat dll and it didn't work. Just the dll didn't work but with both the dll and the -M for the module it did work. There is obviously something included with the module that isn't included in the dll. And XML::Parser::Expat must not have been packed with all of its dependencies since it works with it for me but not without it. My approach didn't need as many dlls linked also. Likely they or some alternatives were included instead. with the -M option. I suppose semantically you are correct that '-M' was not required since you found a different way that works. But that doesn't invalidate my approach and for my approach '-M' was required. My approach was very quick also. I spent a few minutes adding the -M option with the expat module and had it working whereas you only got your pp exe to work by comparing with the output from pp_autolink. Communications modules like SOAP::Lite (which is the source of problems here) need to be able to handle many different protocols using different modules. To do this they try different ones until one works. This is what causes the problem since no one module is needed but at least one path is needed. Making all of the communications modules requirements means many unneeded modules would have to be installed to get SOAP::Lite to work. It is likely that the way your exe runs on the server is not using the same modules as when you run it in your development environment. I don't remember which but some of the modules I found listed with 'require' statements in SOAP::Lite were not installed on my machine and the script was running. I also found internet forum threads about the same error message that suggested fixes with modules that are not in my Perl environment. So that told me there are different modules that can fix this problem. I only needed to get the ones I already had packed into the exe. I recently used pp to solve a similar difficult to pack script that used Data::GUID::Any. This module also had many optional modules that it could use to create GUIDs but I had to pack some of them with the -M option to get it working with pp. This was an interesting challenge and I'm glad to learn more about the -a option you used and your approach of comparing the temp PAR caches. I also plan to try pp_autolink.	[reply] [d/l]