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/par@perl.org/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
