From ActiveState to Strawberry Perl

[Juan José 'Peco' San Martín]

Hi all,
I'm a happy user of PAR during the last 3 years (thank you!, awesome work).
I'm using it to create and deploy an .exe file.

I'm now migrating the PAR-packaging machine from Windows7/ActiveState Perl
5.10 to Windows7/Strawberry Perl 5.20 and I have some issues with the
dependencies...

After some analysis work, saw that in Strawberry I need to pass the
parameter: -I lib -l libxml2-2_.dll to work with XML files.

(not sure why it wasn't needed with ActiveState Perl :-?)

Now, I have some issues with LWP::Protocol::http.pm ... perhaps related to
SSL (https) and the need to pass another DDL to pp.

So, I wondering if exists a way to detect the missing Libs and how they are
called in Strawberry Perl.

The .pl works well.

Thanks a lot for any light.
Peco

[Clive Eisen]

you probably need

-a "C:/strawberry/perl/vendor/lib/Mozilla/CA/cacert.pem;cacert.pem"

That lost me a few hours as well ;-)

as well as any other missing dll - but those requirements pop up if you run the exe on a machine without perl

--
Clive Eisen
GPG: 75056DD0

Post by Juan José 'Peco' San Martín
Hi all,
I'm a happy user of PAR during the last 3 years (thank you!, awesome work). I'm using it to create and deploy an .exe file.
I'm now migrating the PAR-packaging machine from Windows7/ActiveState Perl 5.10 to Windows7/Strawberry Perl 5.20 and I have some issues with the dependencies...
After some analysis work, saw that in Strawberry I need to pass the parameter: -I lib -l libxml2-2_.dll to work with XML files.
(not sure why it wasn't needed with ActiveState Perl :-?)
Now, I have some issues with LWP::Protocol::http.pm ... perhaps related to SSL (https) and the need to pass another DDL to pp.
So, I wondering if exists a way to detect the missing Libs and how they are called in Strawberry Perl.
The .pl works well.
Thanks a lot for any light.
Peco

[Juan José 'Peco' San Martín]

Thanks for the quick answer Clive.

I added the parameter but not luck :-/

If I run the application (.pl) works
If I run the PAR exe (created with ActiveState) works
If I run the PAR exe (created with StrawberryPerl) I get the error:
*Bad file descriptor at LWP/Protocol/http.pm <http://http.pm> line 291*
I'm exhausted :-D

Peco

Post by Clive Eisen
you probably need
-a "C:/strawberry/perl/vendor/lib/Mozilla/CA/cacert.pem;cacert.pem"
That lost me a few hours as well ;-)
as well as any other missing dll - but those requirements pop up if you
run the exe on a machine without perl
--
Clive Eisen
GPG: 75056DD0
On 12 Dec 2014, at 18:23, Juan José 'Peco' San Martín <
Hi all,
I'm a happy user of PAR during the last 3 years (thank you!, awesome
work). I'm using it to create and deploy an .exe file.
I'm now migrating the PAR-packaging machine from Windows7/ActiveState Perl
5.10 to Windows7/Strawberry Perl 5.20 and I have some issues with the
dependencies...
After some analysis work, saw that in Strawberry I need to pass the
parameter: -I lib -l libxml2-2_.dll to work with XML files.
(not sure why it wasn't needed with ActiveState Perl :-?)
Now, I have some issues with LWP::Protocol::http.pm ... perhaps related
to SSL (https) and the need to pass another DDL to pp.
So, I wondering if exists a way to detect the missing Libs and how they
are called in Strawberry Perl.
The .pl works well.
Thanks a lot for any light.
Peco

[Clive Eisen]

Ok so on your install share what is at line 291 of LWP/Protocol/http.pm

--
Clive Eisen
GPG: 75056DD0

Post by Juan José 'Peco' San Martín
Thanks for the quick answer Clive.
I added the parameter but not luck :-/
If I run the application (.pl) works
If I run the PAR exe (created with ActiveState) works
If I run the PAR exe (created with StrawberryPerl) I get the error: Bad file descriptor at LWP/Protocol/http.pm line 291
I'm exhausted :-D
Peco
you probably need
-a "C:/strawberry/perl/vendor/lib/Mozilla/CA/cacert.pem;cacert.pem"
That lost me a few hours as well ;-)
as well as any other missing dll - but those requirements pop up if you run the exe on a machine without perl
--
Clive Eisen
GPG: 75056DD0

Post by Juan José 'Peco' San Martín
Hi all,
I'm a happy user of PAR during the last 3 years (thank you!, awesome work). I'm using it to create and deploy an .exe file.
I'm now migrating the PAR-packaging machine from Windows7/ActiveState Perl 5.10 to Windows7/Strawberry Perl 5.20 and I have some issues with the dependencies...
After some analysis work, saw that in Strawberry I need to pass the parameter: -I lib -l libxml2-2_.dll to work with XML files.
(not sure why it wasn't needed with ActiveState Perl :-?)
Now, I have some issues with LWP::Protocol::http.pm ... perhaps related to SSL (https) and the need to pass another DDL to pp.
So, I wondering if exists a way to detect the missing Libs and how they are called in Strawberry Perl.
The .pl works well.
Thanks a lot for any light.
Peco

[Roderich Schupp]

Post by Clive Eisen
you probably need
-a "C:/strawberry/perl/vendor/lib/Mozilla/CA/cacert.pem;cacert.pem"

That shouldn't be necessary if you have the latest version of
Module::ScanDeps and PAR::Packer.

Cheers, Roderich

[Roderich Schupp]

On Fri, Dec 12, 2014 at 7:23 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
After some analysis work, saw that in Strawberry I need to pass the
parameter: -I lib -l libxml2-2_.dll to work with XML files.
(not sure why it wasn't needed with ActiveState Perl :-?)

It's probably not ActiveState vs Strawberry, but related to how stuff was
built/packaged for Perl 5.10 vs 5.20...

Anyway, I've explained the issue in a previous post to this mailing list

http://www.nntp.perl.org/group/perl.par/2014/10/msg5853.html

The actual problem there was different, but the general explanation still
holds:
If a Perl XS module links to "other" DLLs then these are never implicitly
packed by PAR::Packer,
instead you must figure them out for yourself and explicitly add them on
the pp command (using option -l).

By "other" I don't mean the XS "glue" DLL, eg. XML::LibXML installs the
"glue" DLL .../auto/XML/LibXML/LibXML.dll.
This in turn is linked against the actual (written in C) DLL from the Gnome
libxml2 library, libxml2-2_.dll or similar -
that's the "other" DLL.

Now, I have some issues with LWP::Protocol::http.pm ... perhaps related to

Post by Juan José 'Peco' San Martín
SSL (https) and the need to pass another DDL to pp.

Any SSL related problems with LWP can most likely be traced back to
Net::SSleay: it's "glue" DLL,
...auto/Net/SSLeay/SSLeay.dll, is linked against libssl and libcrypto from
the OpenSSL project.
Note that these DLLs are typically named a bit differently on Windows
systems, eg. ssleay32_.dll and libeay32_.dll.
To further complicate things, these DLLs might even be linked to other
DLLs: libeay32_dll is typically
linked against zlib1_.dll or similar. If that's the case, then you must
explicitly pack it, too.

Post by Juan José 'Peco' San Martín
So, I wondering if exists a way to detect the missing Libs and how they
are called in Strawberry Perl.

Follow steps 1 thru 4 in the above post :)

Cheers, Roderich

[Juan José 'Peco' San Martín]

Thank you for the explanation (again)

I'm looping on the points 1 to 4 without luck, yet. All the DLL of the
world appear to be linked :-P

My current pp is:
pp -I lib -l lixml2-2_.dll -l ssleay32_.dll -l libgcc_S_sjlj-1.dll -M
XML::SAX::PurePerl -M XML::LibXML::SAX -M Net::SSL -M Crypt::Blowfish ...

It makes sense to unzip the version 5.10 and try to identify the DLLs (with
similar names) that I should link on 5.20?

Peco

Post by Roderich Schupp
On Fri, Dec 12, 2014 at 7:23 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
After some analysis work, saw that in Strawberry I need to pass the
parameter: -I lib -l libxml2-2_.dll to work with XML files.
(not sure why it wasn't needed with ActiveState Perl :-?)

It's probably not ActiveState vs Strawberry, but related to how stuff was
built/packaged for Perl 5.10 vs 5.20...
Anyway, I've explained the issue in a previous post to this mailing list
http://www.nntp.perl.org/group/perl.par/2014/10/msg5853.html
The actual problem there was different, but the general explanation still
If a Perl XS module links to "other" DLLs then these are never implicitly
packed by PAR::Packer,
instead you must figure them out for yourself and explicitly add them on
the pp command (using option -l).
By "other" I don't mean the XS "glue" DLL, eg. XML::LibXML installs the
"glue" DLL .../auto/XML/LibXML/LibXML.dll.
This in turn is linked against the actual (written in C) DLL from the
Gnome libxml2 library, libxml2-2_.dll or similar -
that's the "other" DLL.
Now, I have some issues with LWP::Protocol::http.pm ... perhaps related

Post by Juan José 'Peco' San Martín
to SSL (https) and the need to pass another DDL to pp.

Any SSL related problems with LWP can most likely be traced back to
Net::SSleay: it's "glue" DLL,
...auto/Net/SSLeay/SSLeay.dll, is linked against libssl and libcrypto from
the OpenSSL project.
Note that these DLLs are typically named a bit differently on Windows
systems, eg. ssleay32_.dll and libeay32_.dll.
To further complicate things, these DLLs might even be linked to other
DLLs: libeay32_dll is typically
linked against zlib1_.dll or similar. If that's the case, then you must
explicitly pack it, too.

Post by Juan José 'Peco' San Martín
So, I wondering if exists a way to detect the missing Libs and how they
are called in Strawberry Perl.

Follow steps 1 thru 4 in the above post :)
Cheers, Roderich

[Roderich Schupp]

On Fri, Dec 12, 2014 at 11:18 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
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

[Juan José 'Peco' San Martín]

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 BUTeach 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

Post by Roderich Schupp
On Fri, Dec 12, 2014 at 11:18 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
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
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

[Roderich Schupp]

On Sun, Dec 14, 2014 at 6:30 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
I think PAR (Module-ScanDeps) detects "use XX" pushing the needed modules
into the EXE, but why this change the behaviour of the script?

Correct, so the executable should just contain some more modules which
can't hurt, right?
But stranger things have happened...

Try to figure out the difference: create your excutable both with and
without "use XX",
run "unzip -l your.exe" on them (a pp'ed executable is also a zip file),
sort the outputs and run diff on them.

Post by Juan José 'Peco' San Martín
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).

Note that adding *.a libraries is useless in this context. And do NOT
simply add "all DLLs that exist", esp. do NOT add perl520.dll, libgcc*.dll,
libstdc++*.dll, libwinpthread*.dll.

Cheers, Roderich

[Juan José 'Peco' San Martín]

Thank you Roderich.

Interesting!

a) Instead of *use XX,* I looked the dependencies (the "use YYY" inside the
XX module) to find the origin.
Catched: *Net::Bonjour*

b) I have a simple script that works (without *use Net::Bonjour*) and fails
(with *use Net::Bonjour*)
Then I did what you said, Par-exe both and compare.

The one that fails, it's little bit bigger (as expected) and includes these
extra files that make the exe doesn't work

/lib/auto/Digest:SHA
/lib/auto/Net:DNS
/lib/Digest:SHA.pm
/lib/IO/Socket:INET6.pm
/lib/Net:Bonjour
/lib/Net:Bonjour.pm
/lib/Net:DNS
/lib/Net:DNS.pm

My current pp line is

pp -I lib -l libxml2-2_.dll -l ssleay32_.dll -l zlib1_.dll -M
XML::SAX::PurePerl -M XML::LibXML::SAX -M Net::SSL -M Crypt::Blowfish -0
test.exe test.pl

Although we can reproduce the issue with pp -o sample.exe sample.pl

Thanks

Peco

Post by Roderich Schupp
On Sun, Dec 14, 2014 at 6:30 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
I think PAR (Module-ScanDeps) detects "use XX" pushing the needed modules
into the EXE, but why this change the behaviour of the script?

Correct, so the executable should just contain some more modules which
can't hurt, right?
But stranger things have happened...
Try to figure out the difference: create your excutable both with and
without "use XX",
run "unzip -l your.exe" on them (a pp'ed executable is also a zip file),
sort the outputs and run diff on them.

Post by Juan José 'Peco' San Martín
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).

Note that adding *.a libraries is useless in this context. And do NOT
simply add "all DLLs that exist", esp. do NOT add perl520.dll, libgcc*.dll,
libstdc++*.dll, libwinpthread*.dll.
Cheers, Roderich

[Roderich Schupp]

On Sun, Dec 14, 2014 at 7:49 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
The one that fails, it's little bit bigger (as expected) and includes
these extra files that make the exe doesn't work
/lib/auto/Digest:SHA
/lib/auto/Net:DNS
/lib/Digest:SHA.pm
/lib/IO/Socket:INET6.pm
/lib/Net:Bonjour
/lib/Net:Bonjour.pm
/lib/Net:DNS
/lib/Net:DNS.pm

No suprise here: Net::Bonjour depends on Net::DNS which in turn depends on
Digest::SHA and IO::Socket...

Cheers, Roderich

[Pascal Fleer]

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

Post by Juan José 'Peco' San Martín
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.
Virtual machine with Windows 7 + Strawberry Perl 5.20 with the latest PAR.
/use strict;
use warnings;
/
/use LWP::UserAgent;
/
/my $browser = LWP::UserAgent->new();
/
/my $echo=$browser->get('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
On Fri, Dec 12, 2014 at 11:18 PM, Juan José 'Peco' San Martín
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
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

[Juan José 'Peco' San Martín]

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

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
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.
Virtual machine with Windows 7 + Strawberry Perl 5.20 with the latest PAR.
*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

Post by Roderich Schupp
On Fri, Dec 12, 2014 at 11:18 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
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
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

[Roderich Schupp]

On Sun, Dec 14, 2014 at 6:30 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
*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\";}*

What is the actual error message when it fails, e.g. try

*if (not $echo->is_success) { print "no connection: ", $echo->status_line,
"\n";}*


Cheers, Roderich

[Juan José 'Peco' San Martín]

Hi,

$status_line is: 500 write failes: Bad file descriptor

$@ is write failed: Bad file descriptor at LWP/Protocolo/http.pm line 291

Thanks!
Peco

Post by Roderich Schupp
On Sun, Dec 14, 2014 at 6:30 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
*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\";}*

What is the actual error message when it fails, e.g. try
*if (not $echo->is_success) { print "no connection: ", $echo->status_line,
"\n";}*
Cheers, Roderich

[Juan José 'Peco' San Martín]

Hello.

I found that INET6 seems to be broken in some way.
See this: https://rt.cpan.org/Ticket/Display.html?id=83967

If I rename INET6 to whatever, and PAR it, then it seems to work (I'm
checking).
What I do not understand is why it works executing .pl and not the
PAR-exe...

Thanks
Peco

Post by Juan José 'Peco' San Martín
Hi,
$status_line is: 500 write failes: Bad file descriptor
Thanks!
Peco

Post by Roderich Schupp
On Sun, Dec 14, 2014 at 6:30 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
*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\";}*

What is the actual error message when it fails, e.g. try
*if (not $echo->is_success) { print "no connection: ",
$echo->status_line, "\n";}*
Cheers, Roderich

[Roderich Schupp]

On Mon, Dec 15, 2014 at 6:15 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
I found that INET6 seems to be broken in some way.
See this: https://rt.cpan.org/Ticket/Display.html?id=83967

Unfortunately it seems this ticket didn't result in a ticket for
IO::Socket::INET6 to fix this strange behaviour :(

Post by Juan José 'Peco' San Martín
If I rename INET6 to whatever, and PAR it, then it seems to work (I'm
checking).
What I do not understand is why it works executing .pl and not the
PAR-exe...

Me neither, but I'll leave that to another day.

Cheers, Roderich

[Juan José 'Peco' San Martín]

I write just to say thank you to Roderich for the time, effort and patience
in supporting PAR.

Clap-clap

Peco

Post by Roderich Schupp
On Mon, Dec 15, 2014 at 6:15 PM, Juan José 'Peco' San Martín <

Post by Juan José 'Peco' San Martín
I found that INET6 seems to be broken in some way.
See this: https://rt.cpan.org/Ticket/Display.html?id=83967

Unfortunately it seems this ticket didn't result in a ticket for
IO::Socket::INET6 to fix this strange behaviour :(

Post by Juan José 'Peco' San Martín
If I rename INET6 to whatever, and PAR it, then it seems to work (I'm
checking).
What I do not understand is why it works executing .pl and not the
PAR-exe...

Me neither, but I'll leave that to another day.
Cheers, Roderich