Hi, Good point, but unfortunately it has not worked. I disabled the Windows Firewall (to avoid errors) and the behaviour is the same.
Thank you Peco 2014-12-14 19:11 GMT+01:00 Pascal Fleer <[email protected]>: > > > Hi, > > with tools like sysinternals process explorer or process monitor check if > your application does open a socket - you should see something like > "SYN_SENT". > > If this is the case check your local firewall settings if your executable > is blocked. Add an exception for your executable. > > This is very common with Windows 7. > > Pascal > > > > On 14.12.2014 18:30, Juan José 'Peco' San Martín wrote: > > Thank you Roderich. Really appreciate your guide. > > I'm on this during the last xxx hours and now I think I'm in front of a > new issue or completely lost. > > Let me try to summarize: > > Virtual machine with Windows 7 + Strawberry Perl 5.20 with the latest PAR. > > Simple script to do wget: > > > > *use strict; use warnings; * > > > *use LWP::UserAgent; * > > *my $browser = LWP::UserAgent->new(); * > > > *my $echo=$browser->get('http://google.com <http://google.com>'); * > > *if (not $echo->is_success) { print "no connection\n";} * > *else { print "connected\";}* > > It works as .pl, it works as .exe with PAR > Both executions return "connected" > > To this simple script, I add "use XX" (where XX is the main module of my > real application) > Please, note that I'm only doing "use" but I'm not explicitly calling any > subroutine (the module ends with 1;) > > > *use strict; * > > > > > *use warnings; use XX; use LWP::UserAgent; * > > *my $browser.... * > > > > > > * It works as .pl, it works as .exe with PAR BUT each execution returns > different result - .pl => connected - .exe => not connected * > :-?? > > I think PAR (Module-ScanDeps) detects "use XX" pushing the needed > modules into the EXE, but why this change the behaviour of the script? > > It's not sane, but at this point my pp line includes all the DLLs/.a > libraries that exist (double checked with the list of Roderich). The exe is > well created, but with the same results > > Thanks for reading this far :-) > Peco > > 2014-12-14 17:45 GMT+01:00 Roderich Schupp <[email protected] > >: >> >> On Fri, Dec 12, 2014 at 11:18 PM, Juan José 'Peco' San Martín < >> [email protected]> wrote: >> >>> I'm looping on the points 1 to 4 without luck, yet. All the DLL of the >>> world appear to be linked :-P >> >> >> >> Don't dispair, FYI here's a list of Perl modules with "glue" DLLs that >> are linked against external DLLs. >> This was culled from Strawberry 5.20, In addition, modules Tk, >> Alien::wxWidgets and Wx were installed. >> Note that I suppressed >> >> - Windows system DLLs, e.g. KERNEL32.dll, because you obviously don't >> need to pack them >> - DLLs that perl.exe itself recursively depends on, e.g libgcc*.dll >> and libstdc++*.dll, which PAR::Packer takes care of automatically >> >> How to read this list: if your script uses XML::LibXML, find the >> corresponding entry: >> >> XML::LibXML (E:/Strawberry/perl/vendor/lib/auto/XML/LibXML/LibXML.xs.dll) >> libxml2-2_.dll >> libiconv-2_.dll >> liblzma-5_.dll >> zlib1_.dll >> >> This tells you that you need to add >> >> -l libxml2-2_.dll -l libiconv-2_.dll -l liblzma-5_.dll -l zlib1_.dll >> >> to the pp command line. >> >> Cheers, Roderich >> > >
