Ah, I suspected what you mention towards the end of your mail as the error is with the execution of the wrapper exe, not anything inside of it after unpacking. I am in a good position to test this now as after several days of pain, I have VMs of the right versions to try this on.
PK On 13 Mar 2011, at 11:41 PM, Roderich Schupp wrote: > On Sun, Mar 13, 2011 at 2:58 PM, Mark Dootson <[email protected]> wrote: >> On the wider point, PAR::Packer builds with the same flags as Perl is >> configured with - so it's unlikely to be something that can be fixed in >> PAR::Packer alone. > > Actually that's not 100 percent guaranteed. > > PAR::Packer isn't simply an XS module (in fact, its module part is pure Perl), > but it has a rather special implementation. It builds a custom Perl > interpreter > (the parl executable which is also contained in any executable > genererated by pp). > Building a custom Perl generally _is_ covered by ExtUtils::MakeMaker, i.e. the > necessary flags should be found in Config.pm. However, this use case is > seldom exercised nowadays (the need for custom Perl interpreters > vanished with the > introduction of XS in Perl 5), so there may be bugs here. There are known > Perl distributions which get these flags in Config.pm wrong. > > There are also areas where the information in Config.pm doesn't help. > For example, > if your perl was build against a shared libperl.so or some such, > Config.pm will give you the > LDFLAGS to link your custom Perl interpreter against this libperl.so. > But it doesn't > tell you its actual name and location in the filesystem. But we must pack this > shared library into any pp generated executable (otherwise the included custom > Perl interpreter can't run on a machine without a Perl installation), so we > need > to actually find the file. PAR::Packer's build process has to resort > to heuristics > to find the location of the library. > > Also there is a small, self-contained C program (no Perl parts whatsoever). > This is actually the first thing that gets executed when you run any > pp generated executable. In the current PAR::Packer release the Makefile > that's generated from myldr/Makefile.PL does _not_ use Config.pm to get > the flags to build this program. This may already be the cause of the original > problem. If you're adventurous try the version of PAR::Packer from its > Subversion repository where I've started to "convert" myldr/Makefile.PL to > a standard ExtUtill::MakeMaker methods. > > Cheers, Roderich -- Dr Philip Kime
