Hi,
Have just uploaded a working Wx::Perl::Packager to CPAN. Also available as PPM from http://www.wxperl.co.uk/ If you want the source dist and your CPAN mirror does not have it yet, then it is also at http://www/wxperl.co.uk/Wx-Perl-Packager-0.11.tar.gz What's new: On app startup the 3 wxWidgets DLLs directly linked to Wx.dll are extracted as bound files and moved to a separate temporary directory along with mingwm10.dll and gdiplus.dll if required / present. The temp directory is named using the user name, the key for the version of wxWidgets, a key for the version of Wx and a short hash of the file sizes of the wxWidgets DLLs. Which means that app should only ever have to copy them once, (unless they are deleted) and should always get the correct version. This directory is not put on the path - DLLs are loaded directly by Wx::Perl::Packager. The --clean option does not work - but it never did. It is irrelevant in any case for your bound files and hence the wxWidgets dlls. PerlApp always attempts to remove these. The --dyndll option now works. The wxWidgets DLLs are not loaded dynamically, of course. But they are the only components which aren't. There are some new options for the wxpdk utility meaning you no longer end up loading the GUI if you don't want. You can now do: wxpdk -A argfile.args then: perlapp @argfile.args --norunlib --dyndll --gui --exe foo.exe foo.pl so automated builds are supported and use of the PerlApp GUI is not required. You can create a perlapp file without loading the GUI by doing: wxpdk -S foo.pl -P foo.parlapp If you don't want to use wxpdk to create arg files or perlapp files, or you are compiling your own wxWidgets, read the pod. Wx Perl Packager now binds the wxWidgets dlls under different path names - so existing .perlapp files won't work. wxpar now handles gdiplus.dll if wxWidgets is linked to it. I hope it all works for everyone. Regards Mark
