pp fails with IO::Socket::SSL on strawberry perl 5.12
Ulli Horlacher
With the help of Roderich Schupp I was able to install PAR-Packer-1.005
(had problems with dmake) on strawberry perl 5.12 Windows XP.
I can use pp to produce Windows executables which can be run on other
Windows machines without an installed Perl, even Tk is working!
But compiled programs with "use IO::Socket::SSL" will not run on other
machines:
"This application has failed to start because libeay32_.dll was not found."
is the error message I see there.
My application (*) does https communication. How can I tell pp to include this
libeay32_.dll?
So far I use: pp -gui -clean -o schwuppdiwupp.exe schwuppdiwupp.pl
On my developper machine (with strawberry perl 5.12) everything works fine.
But my target machines do not have strawberry perl installed. I need a
standalone program.exe with everything "on board".
(*) http://fex.rus.uni-stuttgart.de/tmp/schwuppdiwupp.pl
--
Ullrich Horlacher Server- und Arbeitsplatzsysteme
Rechenzentrum E-Mail: horl...@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/
Steffen Mueller
Ulli Horlacher wrote:
> My application (*) does https communication. How can I tell pp to include this
> libeay32_.dll?
pp has the -l option for this purpose:
-l, --link=FILE|LIBRARY
Add the given shared library (a.k.a. shared object or DLL) into the
packed file. Also accepts names under library paths; i.e. "-l ncurses"
means the same thing as "-l libncurses.so" or "-l
/usr/local/lib/libncurses.so" in most Unixes. May be specified multiple
times.
Maybe it's sufficient to add "-l eay32_" to the pp invocation? If not,
you can try with the explicit path. Funny dll name, by the way.
Cheers,
Steffen
Ulli Horlacher
> Maybe it's sufficient to add "-l eay32_" to the pp invocation? If not,
> you can try with the explicit path. Funny dll name, by the way.
I tried it with
pp -gui -clean -l eay32_ -o schwuppdiwupp.exe schwuppdiwupp.pl
where the resulting schwuppdiwupp.exe says:
"This application has failed to start because libeay32_.dll was not found."
and
pp -gui -clean -l c:\strawberry\c\bin\libeay32_.dll -o schwuppdiwupp.exe schwuppdiwupp.pl
where the resulting schwuppdiwupp.exe did not start at all. No output, no
error message, nothing.
Next tip? :-)
Xaero
Ulli Horlacher
> If you create the exe with:
> > pp -gui -clean -o schwuppdiwupp.exe schwuppdiwupp.pl
> and put libeay32_.dll in the same folder as schwuppdiwupp.exe and run the exe does it work?
Not quite, but close :-)
Instead of
"This application has failed to start because libeay32_.dll was not found."
I get
"This application has failed to start because libssl32_.dll was not found."
One step further!
Then I copied libssl32_.dll, too ...and... my application is starting!
But after a while I get a runtime error:
"Can't locate unicore/Heavy.pl in @INC (...) at utf8_heavy.pl line 96"
which does not appear when I start schwuppdiwupp.exe on the Windows with
the installed strawberry perl.
I then tried:
pp -gui -clean -o schwuppdiwupp.exe schwuppdiwupp.pl c:\strawberry\perl\lib\unicore\Heavy.pl
but with the same result:
"Can't locate unicore/Heavy.pl in @INC (...) at utf8_heavy.pl line 96"
Xaero
Is it anywhere else in more accessible location?
Roderich Schupp
> You should read the pp pod which has a lot of useful options, infact if you have a few minutes then there is some fantastic documentation in the PAR-Packer tarball contrib folder by Alan Stewart.
You mean contrib/docs/{where_is_it,who_am_i}.txt?
I didn't know about it either :(
> Is it anywhere else in more accessible location?
One should probably convert it to POD format and check for outdated information
(it appears to have been written in 2004). Patches welcome in either
case, of course .
I'll try to mark it up correctly for the next release so that it will
be shown on the
PAR::Packer CPAN page under the "Documentation" section.
Thanks for the suggestion.
Cheers, Roderich
Ulli Horlacher
> I then tried:
>
> pp -gui -clean -o schwuppdiwupp.exe schwuppdiwupp.pl c:\strawberry\perl\lib\unicore\Heavy.pl
>
> but with the same result:
>
> "Can't locate unicore/Heavy.pl in @INC (...) at utf8_heavy.pl line 96"
Same result with
pp -gui -clean -a c:\strawberry\perl\lib\unicore\Heavy.pl -o schwuppdiwupp.exe schwuppdiwupp.pl
and
pp -gui -clean -M c:\strawberry\perl\lib\unicore\Heavy.pl -o schwuppdiwupp.exe schwuppdiwupp.pl
I then added "require 'unicore/Heavy.pl'" to my perl program and compiled
it with:
pp -gui -clean -c -o schwuppdiwupp.exe schwuppdiwupp.pl
This worked!
And finally I removed the manually copied *.dll from the destination
machine and compiled it on the developer machine with:
pp -gui -clean -c -l c:\strawberry\c\bin\libeay32_.dll -l c:\strawberry\c\bin\libssl32_.dll -o schwuppdiwupp.exe schwuppdiwupp.pl
The resulting schwuppdiwupp.exe is now a standalone windows executable
which needs no additonal files and runs on a vanilla windows machine!
Exactly what I wants!
Thanks to all for providing me with hints&tips!
Roderich Schupp
<fram...@rus.uni-stuttgart.de> wrote:
> Instead of
>
> "This application has failed to start because libeay32_.dll was not found."
>
> I get
>
> "This application has failed to start because libssl32_.dll was not found."
>
> One step further!
>
> Then I copied libssl32_.dll, too ...and... my application is starting!
This is a known problem and it's very hard to fix:
XS modules are typically there to bind a C library, say libfoo.dll to
Perl. The script will have
use Foo;
and we will look for a file Foo.pm. But then there's also a "glue"
library Foo.dll which
is linked against the actual libfoo.dll. PAR::Packer (actually
Module::ScanDeps) will
detect the dependency on Foo.pm and Foo.dll (because we can learn that from
Perl stuff), but it doesn't detect the dependency on libfoo.dll. So
the first two items
will be packed, but the last one not.
There is _nothing_ in Perl housekeeping information to detect libfoo.dll.
What's needed is highly platform dependent code to glean that information
from Foo.dll. E.g. on Linux you could
$ readelf -d Foo.so
and then grep its output for NEEDED libraries. But you can't even assume that
any Linux has the readelf utility installed. On Solaris you could
assume that /usr/ccs/bin/dump
is installed, but it has a different output format. On Windows I
dunno, Strawberry has
AFAICT "objdump -ax" (again slightly different output from readelf), but
ActiveState does not come with it (or similar) etc
Unfortunately the Perl core has zero tools for this kind of analysis -
it does a little
of the same investigation during the configure phase of a Perl build,
but it stores
only the results (in Config.pm) for later perusal in the installed
version of Perl.
AFAIK there's no module on CPAN that does this (but I'd be happy if you
prove me wrong).
And this is only the start: once we know that we should look out for libfoo.dll,
we must actually find this file. This means duplicating the library
search algorithm
for the platform. If we've finally found libfoo.dll, we have to repeat
the algorithm
for it (in your example: libeay32_dll depends on libssl_32.dll).
And finally we need some criterion whether to actually pack libfoo.dll
or not. Because on *nix systems, most of these libraries would probably be
"system libraries", i.e. installed in /lib or /usr/lib, and should
_not_ be packed, because
we may assume that they are present on the target machine. Same on Windows:
if libeay32_.dll depends on kernel32.dll, we should _not_ pack
kernel32.dll because
it comes with Windows.
So presently your only option is: pack and try on another machine, if
a library is
missing, add it to the packed exeutable with -l, rinse and repeat.
> But after a while I get a runtime error:
>
> "Can't locate unicore/Heavy.pl in @INC (...) at utf8_heavy.pl line 96"
That's a known problem, cf. #58093. Fixed in Module::Scandeps trunk, but
not released yet.
> which does not appear when I start schwuppdiwupp.exe on the Windows with
> the installed strawberry perl.
The dependency is not detected, hence the file is not packed.
> I then tried:
>
> pp -gui -clean -o schwuppdiwupp.exe schwuppdiwupp.pl c:\strawberry\perl\lib\unicore\Heavy.pl
>
> but with the same result:
Now you explicitly pack the file, but it's stored (internally) in a
different location where
it won't be found at runtime. Anyway, apply the patch from #58093 (and re-pack).
Cheers, Roderich
Ulli Horlacher
> The resulting schwuppdiwupp.exe is now a standalone windows executable
> which needs no additonal files and runs on a vanilla windows machine!
> Exactly what I wants!
>
> Thanks to all for providing me with hints&tips!
schwuppdiwupp is a client for F*EX:
OS independant personal file exchange of *ANY* size. See
http://fex.rus.uni-stuttgart.de/
And as a thank to the PAR developers&maintainers:
If you need a F*EX account: contact me :-)
Roderich Schupp
> You didn't? Wow! It really needs better advertisement then. contrib/ has a
> bunch of useful things. Did you ever add your extraction script there?
_You_ added it :)
> The one gripe I have with the document is that it's talking about the guts
> of how things work rather too much for most users. I'm guessing that's why
> it's hidden in contrib (or because of licensing?).
I'll try to contact Alan. If no one converts it to POD, it will show
up in "Other Files"
on CPAN (but won't be installed on the users's disk) and that will already
show that it's more on the technical side.
Cheers, Roderich
Steffen Mueller
Roderich Schupp wrote:
> On Wed, Jun 9, 2010 at 7:20 PM, Xaero <groun...@gmail.com> wrote:
>> You should read the pp pod which has a lot of useful options,
>> infact if you have a few minutes then there is some fantastic
>> documentation in the PAR-Packer tarball contrib folder by Alan
>> Stewart.
>
> You mean contrib/docs/{where_is_it,who_am_i}.txt? I didn't know about
> it either :(
You didn't? Wow! It really needs better advertisement then. contrib/ has
a bunch of useful things. Did you ever add your extraction script there?
That would be a good candidate for inclusion.
>> Is it anywhere else in more accessible location?
>
> One should probably convert it to POD format and check for outdated
> information (it appears to have been written in 2004). Patches
> welcome in either case, of course .
There may be a few more modes of operation for the extraction nowadays.
I'm thinking of my Archive::Unzip::Burst shortcuts.
> I'll try to mark it up correctly for the next release so that it will
> be shown on the PAR::Packer CPAN page under the "Documentation"
> section.
I totally agree. It's good documentation and I'm still sad that Alan
stopped participating in PAR.*.
The one gripe I have with the document is that it's talking about the
guts of how things work rather too much for most users. I'm guessing
that's why it's hidden in contrib (or because of licensing?). Then
again, the case at hand shows that users sometimes need to be aware of
the underlying mechanisms to address their needs.
It's a trade-off. But in the end, it's probably better to let the user
decide what part of the documentation he wants to read. PAR::Environment
leaks quite a few dirty secrets already.
Cheers,
Steffen
Xaero
- On the computer that you create the exe the files are available in the path so it might not complain. To test it once you create the exe open a new cmd.exe window and set path using the following command:
==CODE==
set PATH=%windir%\system32;%windir%;%windir%\system32wbem
==CODE==
then run the exe from this particular cmd window.
- Use the -c and -x switches when creating the exe and try running the exe.
- If you are still having problems then you will need to manually include the required files using the -l switch. To make the job easier you might want to use the facility argvfile provides (the command line switches can be saved to a file which can be passed to pp during exe creation using >pp @<filename>)
But for now if the previous two options don't work then for each file you get a file missing error copy the file from the strawberry lib to the same folder that the .exe is and run it. Once the app is running without any problems you can then use -l switch and add them to the argvfile and pass them at once to pp.
Regards.
----------------------------------
Xaero
Regards.
----------------------------------