Preventing IO::Socket::SSL caching so that I can get a utility to compile (on windows :/)

tomgracey has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks

It's been a long time since I posted on Perl Monks - it feels good to be back!

On to my problem...

So I know what you're going to say: why oh why are you trying to compile Perl scripts on Windows? I certainly feel the same as I've been tearing what little remains of my hair out on this on and off for a few weeks now. (I haven't been working on this one problem the whole time I should add - that would be a bit extreme!)

Previously I was able to compile my utility without issue. I am not sure whether module updates have caused the problem or something else has changed in the setup of the (virtual) machine I'm using for the compile process. However, the error messages do make the problem fairly obvious (I think). They say things like:

Can't load 'C:\Users\Tom\AppData\Local\Temp\par-5530185324\cache-(lots of digits)\(more digits).xs.dll for module Net::SSLeay...'

To be clear this is after compile has completed, and when I am trying to run the executable that was produced - and when I'm running it on a different Windows machine)

I believe it is ultimately due to one of the SSL related modules (IO::Socket::SSL, LWP::Protocol::https, Net::SSLeay etc) basically caching. The compiler (I'm using pp = the Par Packer) goes ahead and compiles a fixed reference to the cache file in the temp directory. Then the same file can't be found on a different machine.

So at the top level - in my script - I'm using WWW::Mechanize. I guess if I was using IO::Socket::SSL directly, I might be able to do something to influence caching, since I note the docs on this module have a lot of references to a "session_cache". I presume this is the problem. However, I'm confused how I can persuade it to forget about caching, given I don't have a direct interface to it. Perhaps there is an environment variable I can set, or global constants? I have spent a fair amount of time looking over the code in those modules and even putting print/die statements in there, but without much luck. Trial and error is a bit tedious because it involves compiling then transferring to a different machine, only to see the same error pop up.

Very often when I get to this level of frustration it's down to me having missed something obvious that a new set of eyes will find quickly - hence my question on Perl Monks.

I'm using Strawberry Perl 5.6 (32 bit) and compiling on a virtual (box) machine with Windows 7, and I installed all the relevant modules with the cpan shell (if that helps).

Any thoughts would really be appreciated

Thanks!

Comment on Preventing IO::Socket::SSL caching so that I can get a utility to compile (on windows :/) Download Code

Replies are listed 'Best First'.
Re: Preventing IO::Socket::SSL caching so that I can get a utility to compile (on windows :/) by marto (Cardinal) on Feb 17, 2020 at 18:40 UTC
That's an ancient build of perl you have there. Have you tried calling pp with the `--clean` flag to tidy up temporary directories? Can you post an example of how you call pp to package this script?	[reply] [d/l]
Re: Preventing IO::Socket::SSL caching so that I can get a utility to compile (on windows :/) by Anonymous Monk on Feb 17, 2020 at 19:03 UTC
https://github.com/shawnlaffan/perl-pp-autolink	[reply]
Re^2: Preventing IO::Socket::SSL caching so that I can get a utility to compile (on windows :/) by bliako (Abbot) on Feb 18, 2020 at 07:40 UTC
your diagnosis is supported by this PAR::Packer - 'dll not found' error on run -- par packer misses external dependent libraries which one has to add manually or try using the tool you linked.	[reply]
Re: Preventing IO::Socket::SSL caching so that I can get a utility to compile (on windows :/) by thechartist (Monk) on Feb 19, 2020 at 03:07 UTC
I run windows 10, and a recent version of Perl (ie. 5.26 through 5.30) and I've noticed a lot of Net::* failures in my own Windows systems. I'm just starting to wrap my head around this, but it I think there are fundamental inconsistencies between POSIX on *NIX and "POSIX" on Windows that are not likely to be solved anytime soon. That is what some better informed sources tell me. You might want to upgrade Perl on your system if you can.	[reply]
Re: Preventing IO::Socket::SSL caching so that I can get a utility to compile (on windows :/) by tomgracey (Scribe) on Mar 16, 2020 at 14:30 UTC
Many apologies for the (lengthy) delay in response to this. Thanks for all your suggestions. This panned out as follows: The `pp_autolink` suggestion was a good call - thanks for pointing that out. After using this it still spewed out an error message (this time related to trying to write to a file in the temp directory) but it seemed to catch the error and the process continued to execute without other issues. I was able to suppress that error message by adding a hack to `Archive::Zip::Member` to bypass the write. This solved the immediate issue. However I have inherited a whole batch of these scripts which were previously compiled on windows, but now have modification requirements. One thing I wanted to do was optimise some of the download routines by getting them to run in parallel. Again this seemed to work fine with the interpreter, but the compiled version definitely did not want to play ball. So finally I've managed to persuade my client to move the bulk of the processes onto a server, and just have a minimal windows app interface with an API endpoint which does the dirty work. This approach seems to be working a lot better: my client appears happy, and the missing clumps of hair are slowly growing back :) I should say, the `--clean` suggestion was also a good one - I'd not noticed that flag existed. Unfortunately it didn't seem to make a difference in this particular case, but it was a good idea - thanks for pointing it out.	[reply] [d/l] [select]