Provided by: libpar-perl_1.019-1_all bug

NAME

       PAR::FAQ - Frequently Asked Questions about PAR

SYNOPSIS

       This is the Frequently Asked Questions list for the Perl Archive Toolkit.  This (included)
       FAQ list might be outdated. The Wiki version at the above URL is guaranteed to be up to
       date.

DESCRIPTION

   Where is the Windows binary version?
       You can find windows binaries here:

       <http://www.cpan.org/authors/id/S/SM/SMUELLER/>

       There are three ways to install them. Sorted in order of preference:

       cpan

       Run the cpan command line tool that comes with Perl. In the cpan shell, type

         install PAR

       and wait for the script to download and extract PAR and its dependencies. If you have a C
       compiler installed, PAR will be built on your computer for your specific version of Perl.
       If you do not have a C compiler, the installer will look at the site referenced above for
       a compatible binary release and ask you whether you would like to install it.

       ppm

       If you are using ActivePerl from ActiveState, you can use the 'ppm' program that comes
       with the ActiveState Perl. Instructions can be found below. PAR is available from various
       PPM repositories and some packages are compatible with some versions of ActivePerl and not
       with others. There is an incomplete PAR-Win32 Binary Compatibility List at
       <http://par.wikia.com/wiki/PAR_PPM_Compatibility_List> There are at least three relevant
       PPM repositories: The default ActiveState one, the bribes repository which is used in the
       example below and Randy Kobes' repository at <http://theoryx5.uwinnipeg.ca/ppms/>.

           C:\> ppm3
           # activestate was out of date compared to this one
           % rep add bribes http://www.bribes.org/perl/ppm
           # move it to first place on list of repositories
           % rep up bribes
           CPAN>upgrade -install PAR

       And finally, 'q' to quit and that's all :-) You have access to pp and so on...

       manual

       For reference, here's the old explanation of how to install it by hand: The file you need
       will be called PAR-X.XX-MSWin32-x86-multi-thread-Y.Y.Y.par where X.XX is the version of
       PAR you will use and Y.Y.Y is the version of Perl you have. Unzip this file (you may need
       to rename it to end with .zip instead of .par first) and copy all the files in the script
       directory into a directory in your PATH. Now you should be able to use PAR.

   Can PAR bundle all its prerequisites?
       Note: This entry needs serious attention.

       Yes and no.

       It would be possible to do this but it would also introduce a maintenance nightmare. A new
       version of PAR would have to be released whenever a new version of any of the dependencies
       came out. This is already painful with the included Module::Install.

       The original proposal which led to this FAQ entry considered the case where you want to
       install PAR without a working CPAN.pm/CPAN shell installation or without internet
       connectivity. By default, PAR will try to install its dependencies from CPAN using the
       CPAN.pm module.

       Given that you have a development machine with PAR installed and with a working CPAN.pm,
       it is reasonably simple to create one or more .par distributions of PAR's dependencies.
       Install PAR::Dist::FromCPAN. Then you can create .par distributions (read: binaries
       installable with the pure-perl PAR::Dist on the same architecture) for the PAR
       dependencies as follows:

         mkdir par_files
         cpan2par --pattern PAR --follow --out par_files/ --merge --skip File::.*
                  --skip Getopt::Std --skip Carp --skip Data::Dumper --skip Time::Local
                  --skip 'Test\b.*' --skip Text::ParseWords --skip ExtUtils::.*
                  --skip Getopt::Long --skip Text::Abbrev --skip DirHandle --skip Pod::.*

       (Line breaks inserted for readability.) What happens here? cpan2par uses the API of the
       CPAN.pm module to fetch the PAR distribution from CPAN, unpacks it, builds it, creates a
       .par archive from its compiled state and then does the same for any of its dependencies.
       And then for its dependencies dependencies and... You get the idea. This is what the
       --follow option does. We add a couple of --skip options to skip core modules which we need
       not include and any Test::* modules. The --merge option merges all of the .par
       distributions into the original PAR one. Voila! (Future versions of PAR::Dist::FromCPAN
       might include an option --skip-core which would skip any modules contained in the core
       distribution.)

       After this command worked its magic, you should have a single file
       PAR-VERSION-ARCHNAME-PERLVERSION.par in the subdirectory 'par_files/'. You can now install
       PAR and its non-core dependencies on any machine that has the architecture of your
       development system (and a binary compatible perl version) using PAR::Dist as follows:

         perl -MPAR::Dist -einstall_par

       Provided that you run the command from within the directory containing the aforementioned
       .par file (and no other .par file).

       Since you might not even have PAR::Dist on the target machine, you can do this simple hack
       to get a basic installer:

         perl -MPAR::Dist -e'open my $fh, "<", $INC{"PAR/Dist.pm"}; print <$fh>;
              print "\npackage main;\nPAR::Dist::install_par(\@ARGV ? shift(\@ARGV)
              : ());\n\n"'
              > installer.pl

       (Again: Line breaks inserted for readability.) This looks for your installed copy of
       PAR::Dist, reads it, writes it to STDOUT and appends two lines of code: "package main;"
       and a call to PAR::Dist::install_par. By default, it will install any (single) .par file
       in the current directory. If supplied with a file name as first argument, it will install
       the specified file. It should have no non-core dependencies! So shipping the generated
       PAR-....par file and the installer.pl file to the target machine and running "perl
       installer.pl" should just magically install PAR and its dependencies for you.

       Now, this whole trick works equally well for any other modules. In fact, if you have PAR
       on the target machine, you needn't even install the modules in the .par file in order to
       use them! You can just add "use PAR 'foo-bar.par';" to your code and any modules will be
       loaded from the .par file as necessary. ("perl -MPAR=foo-bar.par your_script.pl" works,
       too.) The documentation of the PAR module has details on this.

       Finally, note that you can install PAR::Repository::Client on the target machines and
       subsequently use PAR 0.951 and later to automatically fetch any unfulfilled dependencies
       from a (remote or local) repository:

         use PAR { repository => 'http://my_local_secure_host/repository' };

       or:

         use PAR { repository => 'file:///path/to/repository' };

       Details, again, in the PAR documentation and in the PAR::Repository::Client documentation.

       Answer from: Steffen Mueller, 16 August 2006

   If I try to compile my wxGlade generated script, it doesn't run. What's wrong?
       Note: Is this still a problem?

       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?
       Install the "libperl-dev" package.

       Note that Debian provides (usually up-to-date) packages of the modules in the PAR
       ecosystem: Module::Scandeps, PAR, PAR::Dist and PAR::Packer; the corresponding packages
       are called "libmodule-scandeps-perl",  "libpar-dist-perl", "libpar-perl" and
       "libpar-packer-perl".

   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 :

         zip -r -D hello.par my_dir/

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

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

   On what platforms can I run PAR? On what platforms will the resulting executable run?
       Win32 (95/98/ME/NT4/2K/XP), FreeBSD, Linux, AIX, Solaris, Darwin and Cygwin.

       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 completely hide my source code?
       Not completely, but possible to a degree. Starting from version 0.76, PAR supports an
       input filter mechanism, 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."

       Other than that, I would point you at PAR::Filter::Crypto. Be sure to read the CAVEATS and
       WARNINGS sections of the documentation.

   On Windows XP, pp crashes saying that "par.exe has encountered a problem"
       This is believed to be fixed by PAR 0.76_99. 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.

       This workaround is known not to work in all cases, and the developers are working on a
       solution to the problem. See these posts for more info:

       <http://www.mail-archive.com/par@perl.org/msg00423.html>,
       <http://www.mail-archive.com/par@perl.org/msg00435.html>,
       <http://www.mail-archive.com/par@perl.org/msg00573.html>,
       <http://www.mail-archive.com/par@perl.org/msg00670.html>

   Perl Tk tips
       On Windows XP 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
         error reading bitmap file "" at Tk/Widget.pm line 205.
         at Tk/Widget.pm line 203

       Fix is to find the missing xbm files (perl -V tells you where to start looking) and add
       them to the executable eg

       copy missing xbm files to script directory then:

           % pp --add cbxarrow.xbm --add arrowdownwin.xbm -o test test.pl

   Problem with Win32::Perms and Perms.DLL
       With a script my.pl using Win32::Perms, pp -o my.exe my.pl you may have:

         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 in Perms.dll
       and do pp -o my.exe my.pl ... and everything goes right.

   Under Win32, a pp packed executable has trouble executing other perl scripts or pp packed
       executable
       Note: Is this still current?

       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 system() 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 program 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 can I make a .exe that runs with no console window under Windows?
       Use the --gui switch, ie

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

       I found that this is not documented on all versions of pp ... Some versions have a more
       complete doc than others when you type "pp -h" etc. (This should be reasonably documented
       now.)

       When searching for an answer to this myself, I found many references to using "exetype"
       ... it comes as a .bat with ActivePerl, or you can find an exetype.pl from several places.
       You run "exetype file.exe [WINDOWS|CONSOLE]". This worked, I think, but still did not
       achieve the desired result on my PAR executable. While the exe itself did not generate a
       console window, par.exe (which was invoked in my exe somewhere) DID generate a console
       window, with a titlebar saying "par.exe <strange-looking path to file in temp dir>",
       whereas before changing the console window title bar just displayed the path to my .exe.

   The command line parameters (@ARGV) of a pp-ed binary called from another pp-ed binary are
       missing or broken. What the...?
       This was a bug in releases up to and including PAR-0.90. Please upgrade to PAR 0.91 or
       later and the problem will go away.

   I want to include a pp-ed binary in an RPM package. How can I make this work?
       The binary executables outputted by pp (on Linux) are not valid ELF binaries because it
       basically attaches a zip archive to the binary loader and does not modify the ELF headers
       to reflect that. When building an RPM archive, the validity of the ELF headers is checked
       by default. This can result in problems when packaging pp-ed binaries in RPM archives.

       Scott McBrien helped track down what can be done to get this to work:

         [I]t appears that the RPM archive that is generated gets a list of
         the MD5 sums for components of the executable file calculated by
         prelink.  By disabling prelink, it fixed the problem; in my RPM .spec
         file:
         %define         __prelink_undo_cmd     %{nil}

       After quite some time, it seems like the smart folks at Redhat found the culprit. I'm glad
       *they* did, because I wouldn't have:

         It appears that we found a solution that works. It like the pp
         executables are already stripped, so we don't want rpm stripping them
         again, which, of course, renders them useless.

         In this case, we added the following lines to the spec file to keep rpm
         from running the strip process and not produce debuginfo packages:

         %define __spec_install_post :
         %define debug_package %{nil}

         Don't forget to add the ":" character to __spec_install_post as above or
         this won't work.

       Much praise to all who helped track this down! The discussion can be found in the
       following RT tickets: <http://rt.cpan.org/Public/Bug/Display.html?id=18536|#18536> and
       <http://rt.cpan.org/Public/Bug/Display.html?id=19609|#19609>.

       -- Steffen Mueller, 22 July 2006

   How can I package Wx applications?
       Have a look at the separately maintained Wx::Perl::Packager module.

       -- Steffen Mueller, 3 July 2006

   How can I package Catalyst web applications?
       Catalyst has some builtin PAR support. I found the following URL to be very helpful:

       <http://catalyst.infogami.com/cookbook/par>.

       -- Steffen Mueller, 21 July 2006

   The resulting files are huge! How can I reduce the size of the output file?
       The executables generated by pp generally contain a copy of your Perl shared libraries,
       the Perl core modules and any module dependencies your packaged application may have. That
       is a lot. Sometimes, PAR packages too much. It adheres to the philosophy of rather making
       the application work than generating a streamlined executable. If you want to optimize
       this, you will have to do so by excluding specific modules.

       Chris Dolan's recent post to the PAR mailing list explains this well. Quoting Chris:
       (<http://www.nntp.perl.org/group/perl.par/2490>)

         [...]
         I've found a few tricks that can help a lot:

         * If you know the target platform has Perl pre-installed (e.g. Mac OS X)
           then use the "--dependent" flag. This skips all of the core modules,
           yielding a much smaller executable.

           One significant caveat is moving to older systems.  For example,
           Mac OS X 10.2 had Perl 5.6.0 which has 146 fewer core modules than
           Perl 5.8.6 which shipped with Mac OS X 10.4, and (even more significantly)
           is binary-incompatible with any extra XS modules added from CPAN.
           Other platforms can be even harder to predict.

         * Watch for modules that pull in lots of dependencies

           A good example is DBI.  If your program uses DBI, then Module::ScanDeps
           pulls in ALL of the DBD::* modules (some of which are large) installed on
           your system, because it cannot realistically parse the DBI->connect()
           arguments which specify which database drivers are actually needed.
           In one of my MySQL-based applications, I use this invocation of PAR:

             pp -X DBD::SQLite -X DBD::CSV -X DBD::File -X DBD::Excel

           which saves quite a few bytes, because both DBD::SQLite and DBD::Excel
           have lots of CPAN dependencies.  The actual list if DBD::* modules you
           need to exclude depends on your system.  Here's a short command that will
           reveal all DBD::* modules on a unix-like system:

             perl -MModule::ScanDeps -le'print for map {"DBD/".$_->{name}} Module::ScanDeps::_glob_in_inc("DBD")'

           Another smaller example is SOAP::Transport::* where most installations
           only need SOAP::Transport::HTTP.
           [...]

       Similar techniques can be applied when a module makes use of Module::Pluggable for
       plugins.

       Finally, there is a PAR filter available as a separate distribution on CPAN which
       compresses the source code as much as possible by first parsing it using PPI and then
       spitting out a reduced functional equivalent: PAR::Filter::Squish.

       -- Steffen Mueller, August 2006

   How do I use Win32::GUI::SplashScreen with PAR?
       When using pp to package an application that uses Win32::GUI::SplashScreen, try adding the
       splashscreen bitmap manually as suggested in the Win32::GUI::SplashScreen docs:

         pp -a SPLASHFILE.bmp -o xxx.exe xxx.pl

   The Perl Packager scripts says that it can create executable that runs in same OS. Can I use
       it to create Win32 binary with linux machine? Or what should I use to create Win32
       executable binary on linux from my script?
       It is not possible to create stand-alone binaries for different platform than what you are
       currently running on. This is a generally hard problem since you would have to cross-
       compile all XS modules and perl itself. Not nice.

       For example, if you would like to develop an application on Linux and ship it for both
       Linux/x86 and Win32/x86, it works well to set up a Virtual Machine with a Windows (XP or
       2000 or whatever) and a Perl installation. On that machine, use PAR/pp to package your
       application for Win32.

       See also the question "On what platforms can I run PAR? On what platforms will the
       resulting executable run?".

       -- Steffen Mueller, 2 November 2006

SEE ALSO

       PAR, PAR::Tutorial

AUTHORS

       Audrey Tang <cpan@audreyt.org>, Steffen Mueller <smueller@cpan.org>

       You can write to the mailing list at <par@perl.org>, or send an empty mail to
       <par-subscribe@perl.org> to participate in the discussion.

       Please submit bug reports to <bug-par@rt.cpan.org>.

COPYRIGHT

       Copyright 2003-2008 by Audrey Tang <cpan@audreyt.org>.

       This document is free documentation; you can redistribute it and/or modify it under the
       same terms as Perl itself.

       See LICENSE.