Oops
This is already fixed in trunk.
I'll run around the pitch 5 times for not paying attention.
Mark Dootson wrote:
Hi,
This is, I think, a bug in the way PAR::Packer determines the name of
libperl at make time which is basically to take $Config::Config{libperl}
and append the 'so' extension for dynamic Perls.
So, in a VC++ built Perl on MSWin, such as ActivePerl, we get
$Config::Config{libperl} eq 'perl510.lib'
whilst for a MinGW built Perl like Strawberry we get
$Config::Config{libperl} eq 'libperl510.a'
..
All the test succeed because perl510.dll is on the path.
I think the way to fix this is to have an MSWin specific check for a
dynamic libperl in the appropriate makefile that strips any leading
'lib' from $Config::Config{libperl}and then looks for the DLL under that
name. Note this will only have any effect if the DLL name so determined
actually exists so I can't think of any effect other than that this will
make PAR::Packer on Strawberry work.
Any other thoughts? Is there a simpler way to find out the name of the
dynamic Perl DLL on MSWin?
If this is a reasonable approach I don't mind doing a simple patch and
testing against various Win32 Perls to ensure it works.
The current test I assume fails is in myldr/Makefile.PL at around line 135.
Regards
Mark
Robert Davis wrote:
I have strawberry perl installed.
I have PAR .980 installed.
I did what Roderich Schupp suggested from a previous thread:
http://www.mail-archive.com/[email protected]/msg03147.html
- installed Strawberry Perl 5.10 from scratch
- installed libwin32, PAR, PAR::Packer (and its prerequisites) from CPAN
- pp -o hello.exe -e "print qq[hullo world\n]"
- invoked hello.exe from another console window with everything
mentioning
strawberries removed from environment:
didn't work for me.
I verified the only missing dll was perl510.dll. I copied perl510.dll to
the current directory and it worked.
I checked the cache directory(after cleaning it first) and there is a
libperl510.a in there but no perl510.dll
Help
bob
