Re^3: Problems running a packaged script.

[Lotus1]

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.