Wed Sep 22 09:55:57 2010: Request 61528 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR
Subject: bug similar to RT 55994
Broken in: (no value)
Severity: (no value)
Owner: RSCHUPP
Requestors: edzar...@aegis-usa.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=61528 >
On 2010-09-21 14:51:29, edzar...@aegis-usa.com wrote:
> Re: similar to RT 55994 Par::Packer
> bug -- Can't call method "remove" on an undefined value...(in test
> trying to
> add an icon)
Many thanks for the analysis.
These heuristics in myldr/Makefile.PL for "is our C compiler gcc?"
etc are absolutely horrible. The only defense is that even
ExtUtils::MakeMaker in its latest revision does it, too.
Can you try the latest PAR::Packer (1.007) and change line 106
of myldr/Makefile.PL (as you suggested) from
} elsif ($cc =~ m/^gcc\b/i or ($cc =~ m/^cc\b/i and $gccversion)) {
to
} elsif ($cc =~ m/\bgcc\b/i or ($cc =~ m/\bcc\b/i and $gccversion)) {
and check if it works?
Also, let me know if there's any other problem with
PAR::Packer 1.007 and your ActiveState 5.8.9.
There are probably other places where heuristics of this kind
go wrong. As a quick example I just tried ActiveState 5.10.1
with the MingW compiler that comes with Strawberry perl
(should work in theory). But the heuristics didn't find perl510.lib,
so par.exe didn't even link :( Looks like ldopts() from ExtUtils::Embed
is the culprit here.
Cheers, Roderich
