PAR::FAQ man page on OpenServer

PAR::FAQ man page on OpenServer

Man page or keyword search:
man Server 5388 pages
apropos Keyword Search (all sections)
Output format

PAR::FAQ(3) User Contributed Perl Documentation PAR::FAQ(3)

NAME
PAR::FAQ - Frequently Asked Questions about PAR

SYNOPSIS
This is the Frequently Asked Questions list for the Perl Archive Tool-
kit. You can edit this document at <http://par.perl.org/?FAQ> online.

DESCRIPTION
How do I make a .par file for my CPAN module along with the .tar.gz
file?

Do this in the module directory:

% make clean
% parl -p

You may also digitally sign the generated .par file:

% parl -s

PAR::Dist expects to find your MANIFEST in the current directory, and
uses Module::Signature to (optionally) sign the newly generated PAR.

The .par file can be uploaded to CPAN along with your module's .tar.gz
file. Users of your module can then install from CPAN with a single
command:

% parl -i cpan://PAUSEID/DISTNAME-0.01

Where "PAUSEID" is your PAUSE ID, and "DISTNAME" is your module's dis-
tribution name (eg. "Acme-FooBar").

If I try to compile my wxGlade generated script, it doesn't run. What's
wrong?

Comment out the line that starts with "unless (caller)", and compile it
again. Note that this is considered a bug; clearing the caller stack
is a development in progress.

I get a "link error: /usr/bin/ld: cannot find -lperl" during the "make"
step of the installation on Debian. What's wrong?

You need to install the libperl-dev package.

Alternatively, create a symbolic link from libperl.so.5.6.1 to
libperl.so in /usr/lib:

% cd /usr/lib; ln -s libperl.so.5.6.1 libperl.so

and re-run the "make" step of the installation.

I specify a .ico file with "--icon" for Win32, but the icon is still
the black and white camel. What's wrong?

Unlike Perl2EXE, which can use a standard 16-color bitmap as an appli-
cation icon, PAR requires a true Windows icon file. Download a trial
version of Microangelo (<http://www.microangelo.us/>) and use that to
create your .ico file.

The latest Netpbm tools at <http://netpbm.sourceforge.net/> has ppm-
towinicon, which can tack a pbm and convert it to a windows icon. It
is open source and has win32 ports.

I added a directory to my PAR file using "zip -r" or winzip, and then
generated an executable from this PAR file, and the executable failed
to run (IO error: reading header signature :..). What's wrong?

As pointed out by Alan Stewart, zip adds a directory entry for the new
directory, and it causes the PAR executable to fail.

Just use this :

zip -r -D hello.par my_dir/

or the Archive::Zip::addTree as follows :

$zip->addTree( $root, $dest, sub { -f } )

PAR version 0.81 and above supports adding whole directories with "pp
-A", so you do not normally need to add directories this way.

On what platforms can I run PAR? On what platforms will the resulting
executable run?

Win32 (with VC++ or MinGW), FreeBSD, NetBSD, Linux, MacOSX, Cygwin,
AIX, Solaris, HP-UX, Tru64.

The resulting executable will run on any platforms that supports the
binary format of the generating platform.

How do I extract my script out of packed executable?

In other words, "I did a "pp foo.pl" and I lost foo.pl, how do I get it
back?".

The answer is to just use unzip/winzip/winrar/whatever to decompress
the executable, treating it like a normal Zip file. You may need to
rename the executable into a .zip extension first.

Can PAR completly hide my source code?

Not completely, but possible to a degree. PAR supports an input filter
mechanism via "pp -f" and "pp -F" (see PAR::Filter), which can be used
to implement source obfuscators (or even product activation schemes).

But if you are looking for 100% bulletproof way of hiding source code,
it is not possible with any language. Learning Perl, 3rd Edition has
this answer to offer (quoted with permission from Randal Schwartz):

If you're wishing for an opaque binary, though, we have to tell
you that they don't exist. If someone can install and run your
program, they can turn it back into source code. Granted, this
won't necessarily be the same source that you started with, but
it will be some kind of source code. The real way to keep your
secret algorithm a secret is, alas, to apply the proper number
of attorneys; they can write a license that says "you can do
this with the code, but you can't do that. And if you break our
rules, we've got the proper number of attorneys to ensure that
you'll regret it."

Perl Tk tips

On Microsoft Windows, start your script with

use strict;
use Encode::Unicode;
use Tk;

Some widgets use xbm bitmaps which don't get picked up by PAR. The
error is:

couldn't read bitmap file "": No such file or directory at Tk/Widget.pm line 203
error reading bitmap file "" at Tk/Widget.pm line 205.

Fix is to find the missing xbm files ("perl -V" tells you where to
start looking), copy them to the script directory, and add them to the
executable:

pp -a cbxarrow.xbm -a arrowdownwin.xbm -o test test.pl

Under Win32, a pp packed executable has trouble executing other perl
scripts or pp packed executable.

Note that this problem should only happen if the perl version of both
programs are binary-incompatible.

When running on a Win32 system, if a perl script is packed with pp and
invokes another Perl script or pp packed executable, either with "sys-
tem()" or backticks, the invoked program runs with the copy of
perl5x.dll already loaded into memory.

If the calling executable was packed with "pp -d", the perl5x.dll is
the one from the installed perl bin directory. Otherwise, it is the
one packed with the executable.

The perl5x.dll from the bin dir knows the @INC paths for the installed
libraries; the one in the executable does not. Because of this, a pro-
gram packed without "-d" calling a program with packed with "-d" or
calling perl.exe to run a plain Perl script may fail. This is a Win32
limitation.

How do I make a .exe that runs with no console window under Windows?

Use the "pp --gui" option, like this:

% pp --gui -o file.exe file.pl

How do I change the Icon of the generated .exe file under Windows?

Use the "pp --icon" option, like this:

% pp --icon "c:\path\to\MyIcon.ico" -o file.exe file.pl

On Windows XP, "pp" crashes saying that "par.exe has encountered a
problem"

This bug has been be fixed. The following answer applies to PAR 0.76
and earlier:

You may be able to escape this problem by setting some executables to
Windows 95 compatibility mode. Specifically, find parl.exe (probably
in C:\perl\5.8.0\bin) using Windows Explorer, and right-click on it and
choose "Properties". Choose the "Compatibility" tab and tick the box
for "Run this program with compatibility mode for" and check that the
dropdown shows "Windows 95". Then click OK.

Now you can hopefully run pp as normal to generate an EXE. Before you
can run the generated EXE, you'll need to set its compatibility mode
too, in the same way as you did for parl.exe.

Problem with Win32::Perms and Perms.DLL

This bug has been be fixed. The following answer applies to PAR 0.79
and earlier:

With a script my.pl using Win32::Perms, running "pp -o my.exe my.pl"
may produce this:

Can't locate loadable object for module Win32::Perms in @INC (@INC
contains: CODE(0xb97eec) CODE(0xc8a99c) .) at ../blib/lib/PAR/Heavy.pm
line 78

In fact the dll is Perms.DLL wit DLL in capital letters. That's the
problem. The bootstrap function of PAR in the Dynaloader module fails
looking for Perms.dll in the table of dlls which contains only
Perms.DLL.

And so the solution is just rename Perms.DLL to Perms.dll and do "pp -o
my.exe my.pl" again... and everything goes right!

Problems with chdir() and relative @INC paths

If a perl program's @INC list contains relative paths and that program
calls chdir before loading a module via "require", its behavior can be
different from a PAR-packed executable based on that program. This is
because "pp" typically gleans the module loads without executing code,
so it doesn't see the "chdir". Note that this primarily affects devel-
opers who routinely use "-Mblib" or "-I inc" etc.

Here's a simple workaround to turn your relative @INC paths into abso-
lute paths before "chdir".

require File::Spec;
for (@INC) {
if (! ref $_ && -d $_ && !File::Spec->file_name_is_absolute($_)) {
$_ = File::Spec->rel2abs($_);
}
}

Source: <http://www.nntp.perl.org/group/perl.par/2281>

My PAR executable needs some dynamic libraries

If you use a Perl module that is tied to a dynamic library (that is, a
".dll", ".so" or ".dylib") via XS then PAR will not automatically
detect and include that dependency. This omission can cause problems
when the PAR package is executed on a machine that lacks the library.
The symptom can look something like this error message:

Can't load '/tmp/par-dave/cache-f5cc9fa27d926a299b2883dcef7dbc7aed777aff/2cffd144.bundle'
for module Image::Imlib2:
dlopen(/tmp/par-dave/cache-f5cc9fa27d926a299b2883dcef7dbc7aed777aff/2cffd144.bundle, 1):
Library not loaded: /sw/lib/libImlib2.1.dylib

The key is the last line. This can be solved by adding a "-l" flag to
"pp" like so:

% pp -l /sw/lib/libImlib2.1.dylib -o foo foo.pl

However, this will go badly if that path is actually a symlink, because
PAR mistakenly includes the wrong filename. On my computer I see that
this is the case:

% ls -l /sw/lib/libImlib2*
-rwxr-xr-x 1 root admin 797472 Feb 19 14:49 /sw/lib/libImlib2.1.2.1.dylib
lrwxr-xr-x 1 root admin 21 Feb 27 08:34 /sw/lib/libImlib2.1.dylib -> libImlib2.1.2.1.dylib
-rw-r--r-- 1 root admin 916400 Feb 19 14:49 /sw/lib/libImlib2.a
lrwxr-xr-x 1 root admin 21 Feb 27 08:34 /sw/lib/libImlib2.dylib -> libImlib2.1.2.1.dylib
-rwxr-xr-x 1 root admin 941 Feb 19 14:49 /sw/lib/libImlib2.la

A workaround is to make a copy of the library before running "pp".
This resolves the symlink and creates a real file that "pp" can injest:

% cp /sw/lib/libImlib2.1.dylib .
% pp -l libImlib2.1.dylib -o foo foo.pl

[Note: Imlib2 posed particular problems due to hard-coded paths. Email
cdolan at cpan.org for some nasty hacks if you need to bundle Imlib2]