PAR assistant for packaging Wx applications on MSWin and Linux run 'wxpar' exactly as you would run pp. e.g. wxpar --gui --icon=myicon.ico -o myprog.exe myscript.pl At the start of your script ... use Wx::Perl::Packager; use Wx; ..... or if you use threads with your application use threads; use threads::shared; use Wx::Perl::Packager; use Wx Wx::Perl::Packager must be loaded before any part of Wx so should appear at the top of your main script. If you load any part of Wx in a BEGIN block, then you must load Wx::Perl::Packager before it in your first BEGIN block. This may cause you problems if you use threads within your Wx application. The threads documentation advises against loading threads in a BEGIN block - so don't do it. wxpar will accept a single named argument that allows you to define how the wxWidgets libraries are named on GTK. wxpar ordinarily packages the libraries as wxbase28u_somename.so.0 This will always work if using Wx::Perl::Packager. However, it maybe that you don't want to use Wx::Perl::Packager, in which case you need the correct extension. For most installations the default '.0' IS the correct extension - so in most cases you need do nothing. If, however, you receive errors that suggest, for example, that wxbase28u_somename.so.5 could not be found, you want librararies packaged as wxbase28u_somename.so.5 so pass two arguments to wxpar as wxpar wxextension .5 If you want wxbase28u_somename.so.0.6.0 , for example wxpar wxextension .0.6.0 which would mean a full line something like wxpar wxextension .0.6.0 -o myprog.exe myscript.pl NOTE: the arguments must be FIRST and WILL BREAK Wx::Perl::Packager (which should not be needed in this case as all libraries should be on your LD_LIBRARY_PATH and named so that your par binary finds them). OF COURSE - the symlinks must actually exist. :-) - That is, if you pass wxpar wxextension .0.6.0 -o myprog.exe myscript.pl then wxbase28u_somename.so.0.6.0 etc. must be real files or symlinks on your system.