Skip Menu |

This queue is for tickets about the PAR CPAN distribution.

Report information
The Basics
Id: 61528
Status: resolved
Priority: 0/
Queue: PAR

People
Owner: RSCHUPP [...] cpan.org
Requestors: edzarger [...] aegis-usa.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: bug similar to RT 55994
Date: Tue, 21 Sep 2010 14:44:39 -0400
To: <bug-PAR [...] rt.cpan.org>
From: "Ed Zarger" <edzarger [...] aegis-usa.com>
Re: similar to RT 55994 Par::Packer bug -- Can't call method "remove" on an undefined value...(in test trying to add an icon) Active State Perl 5.8.9 MinGW GCC Par::Packer 0.991 (which was the highest version showing successful build on Win32 and 5.8.9 in the CPAN Testers Matrix) Windows XP Professional SP3 (There may be some packages built with a slightly lower Perl 5.8.version.) Even after manually applying the patch in the bug report resolution, (and maybe another patch or two for other things) I continued to get the same error. After a few weeks, I found a solution for my case. This allowed me to get through all the tests with PASS, and to install the package or module. In case this comes up again, or someone else has related problems... This problem shows up because of a line in the myldr\Makefile.PL That file is similar in the 1.007 version (for these lines). line 70 my $cc = $Config{cc}; sets the location of the compiler. In my autogenerated Makefile in the same directory is line 7 CC=C:/MinGW/bin/gcc.exe Line 106 in myldr\Makefile.PL } elsif ($cc =~ m/^gcc\b/i or ($cc =~ m/^cc\b/i and $gccversion)) { As that line stands, it wants $cc to start with gcc, when it begins with C:/MinGW So it won't find the $cc My solution (good enough for my purposes) was line 106:} elsif ($cc =~ m/gcc\b/i or ($cc =~ m/^cc\b/i and $gccversion)) { So I just looked for "gcc" anywhere in $cc. If you wanted to be more rigorous, you could split the path by the slash, and use the old line 106 to compare the last array entry with the ^gcc. The important line that this affects is line 111 $res = ($^O =~ /^(?:MSWin|cygwin)/) ? 'win32.coff' : ''; since we want $res to = 'win32.coff' In the autogenerated Makefile, this value shows up in the line for "OBJECTS =", and in the line after "$static.exe". Without this change, the Resources Section is never created. My apologies for wasting your time if this has been corrected by any of the other adjustments you've made since then. I just thought I should pass it along to you, since my googling hasn't found the same fix. Ed Zarger AG Aegis Company, Inc. PO Box 153 637 N Center St Corry PA 16407 814-664-8103 Ext 233 800-669-8103 Ext 233 FAX 814-664-9689
On 2010-09-21 14:51:29, edzarger@aegis-usa.com wrote: Show quoted text
> 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
Subject: Re: [rt.cpan.org #61528] bug similar to RT 55994
Date: Sat, 25 Sep 2010 13:28:55 -0400
To: <bug-PAR [...] rt.cpan.org>
From: "Ed Zarger" <edzarger [...] aegis-usa.com>
Thanks for the quick response. I tried Par::Packer 1.007, with the line 106 change through the perl Makefile.PL and dmake test steps. The Makefile warned that I didn't have the prerequisite versions of Module:ScanDeps and PAR. Without upgrading those, I tried the dmake test. All of the t/30 tests passed, particularly the add resource and add icon steps. There were 2 failed tests at the end, in the t/90-rt59710, apparently Unicode based glitches. I have not yet looked through online discussions of those. (I also did not do a completely "clean" check. I left the 0.991 version with the regular Perl locations, and tried 1.007 in another subdirectory. So there may be a bit of the tests looking to C:/Perl/site/bin,etc.) Just thought I'd let you know the cursory results, before I look more critically at it. Ed Zarger AG Aegis Company, Inc. PO Box 153 637 N Center St Corry PA 16407 814-664-8103 Ext 233 800-669-8103 Ext 233 FAX 814-664-9689 Show quoted text
----- Original Message ----- From: "Roderich Schupp via RT" <bug-PAR@rt.cpan.org> To: <edzarger@aegis-usa.com> Sent: Wednesday, September 22, 2010 9:55 AM Subject: [rt.cpan.org #61528] bug similar to RT 55994
> <URL: https://rt.cpan.org/Ticket/Display.html?id=61528 > > > On 2010-09-21 14:51:29, edzarger@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 > >
Subject: Re: [rt.cpan.org #61528] bug similar to RT 55994
Date: Sat, 25 Sep 2010 14:29:12 -0400
To: <bug-PAR [...] rt.cpan.org>
From: "Ed Zarger" <edzarger [...] aegis-usa.com>
After upgrading to Module::ScanDeps 0.98 and PAR 1.002, PAR::Packer 1.007 passed all tests and installed into my computer Windows XP SP3 ActiveState Perl 5.8.9 MinGW gcc ,showing 3.4.2 during set-up (with the mentioned change to myldr/Makefile.PL line 106) Thanks. Ed Zarger Show quoted text
----- Original Message ----- From: "Roderich Schupp via RT" <bug-PAR@rt.cpan.org> To: <edzarger@aegis-usa.com> Sent: Wednesday, September 22, 2010 9:55 AM Subject: [rt.cpan.org #61528] bug similar to RT 55994
> <URL: https://rt.cpan.org/Ticket/Display.html?id=61528 > > > On 2010-09-21 14:51:29, edzarger@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 > >
On 2010-09-25 14:36:09, edzarger@aegis-usa.com wrote: Show quoted text
> After upgrading to Module::ScanDeps 0.98 and PAR 1.002, > PAR::Packer 1.007 passed all tests and installed into my computer > Windows XP SP3 > ActiveState Perl 5.8.9 > MinGW gcc ,showing 3.4.2 during set-up > (with the mentioned change to myldr/Makefile.PL line 106)
I just committed the above fix, will be in the next release of PAR::Packer. Show quoted text
> There were 2 failed tests at the end, in the t/90-rt59710, > apparently Unicode based glitches.
This test depends on a more recent version of Module::ScanDeps, but you already resolved that. Thanks again for investigating and testing, Roderich