Skip Menu |

This queue is for tickets about the PAR-Packer CPAN distribution.

Report information
The Basics
Id: 54074
Status: resolved
Priority: 0/
Queue: PAR-Packer

People
Owner: Nobody in particular
Requestors: m.nooning [...] comcast.net
Cc:
AdminCc:

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



Subject: PAR test fails a gui test with Win32/Exe.pm
<code> Most of this was mentioned in Bug #52794, but there is a different bug, too. As mentioned in 52794, PAR.pl needs PAR/Filter/PodStrip.pm, but PAR/Filter/PodStrip.pm is installed with PAR.pl. In a fresh Perl install, since PodStrip.pm is not there, there are a lot of "Can't find" messages, and the said output verbiage interferes with the t/20 tests. Because of that, we cannot spot the bug subject here. Namely, that one of the t/20 tests that tests a gui switch fails. The current solution to the first problem (for me, that is) is to simply install PAR::Packer, just to get the PodStrip.pm installed. Then I can rerun the "dmake test" to see if there are any "real" bugs. There is. Test pp_gui_tests fails. I will paste the relevant parts of the results below. C:\temp\PAR-Packer-1.002>dmake test ... etcetera, etcetera, ... t/10-parl-generation.t ... ok t/20-pp.t ................ 31/34 Can't call method "remove" on an undefined value at C:/Perl/site/lib/Win32/Exe.pm line 220. # Failed test 'pp_gui_tests t/20-pp.t ................ 32/34 # amsg572: sub pp_gui_tests cannot system pp --gui --icon hi.ico -o hello.exe hello.pl:No such file or directory: # ' # at automated_pp_test.pl line 8446. t/20-pp.t ................ 34/34 # Looks like you failed 1 test of 34. t/20-pp.t ................ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/34 subtests t/30-current_exec.t ... etcetera, etcetera, ... </code>
From: snaury [...] gmail.com
Чтв Янв 28 15:01:56 2010, m.nooning@comcast.net писал: Show quoted text
> As mentioned in 52794, PAR.pl needs PAR/Filter/PodStrip.pm, but > PAR/Filter/PodStrip.pm is installed with PAR.pl. In a fresh Perl > install, since PodStrip.pm is not there,
This issue has nothing to do with whether or not PAR/Filter/PodStrip.pm is installed or not. This issue is because of backslashes. When you are installing PAR::Packer it builds itself in blib and $INC to blib has backslashes. As a result PAR/Filter/PodStrip.pm is not packed and you have this issue. To fix, open script/par.pl and remove the line that reads: if ($Config{_delim} eq '\\') { s{\\}{/}g for @inc } You will see that it works afterwards.
Subject: Re: [rt.cpan.org #54074] PAR test fails a gui test with Win32/Exe.pm
Date: Tue, 02 Feb 2010 08:20:07 -0500
To: bug-PAR-Packer [...] rt.cpan.org
From: Malcolm Nooning <m.nooning [...] comcast.net>
Show quoted text
>To fix, open script/par.pl and remove the line that
#if ($Config{_delim} eq '\\') { s{\\}{/}g for @inc } Granted that this solves the problem with PodStrip.pm problem, there is still the problem in that the test cannot do pp --gui --icon hi.ico -o hello.exe hello.pl I cannot do it by hand, either, as shown in the paste further below. Also, there is a weird parlu9ejbKb.exe, also shown below. By the way, this is with Perl 5.10.1, mingw with gcc 3.4.5. -------Paste C:\tmp>dir 02/02/2010 08:12 AM 17 hello.pl 04/04/2007 04:25 PM 5,694 hi.ico C:\tmp>pp --gui --icon hi.ico -o hello.exe hello.pl Set up gcc environment - 3.4.5 (mingw special) Can't call method "remove" on an undefined value at C:/Perl/site/lib/Win32/Exe.pm line 220. C:\tmp>dir 02/02/2010 08:12 AM 17 hello.pl 04/04/2007 04:25 PM 5,694 hi.ico 02/02/2010 08:14 AM 1,937,553 parlu9ejbKb.exe
From: snaury [...] gmail.com
Втр Фев 02 08:21:09 2010, m.nooning@comcast.net писал: Show quoted text
> C:\tmp>pp --gui --icon hi.ico -o hello.exe hello.pl > Set up gcc environment - 3.4.5 (mingw special) > > Can't call method "remove" on an undefined value at > C:/Perl/site/lib/Win32/Exe.pm line 220.
Just tried it on Strawberry Perl 5.10.1.0 and there's no such issue. It generates hello.exe and I can even see that icon was injected successfully with both Explorer and ResHacker. Strawberry has Win32::Exe 0.11, and the fact that this happens inside Win32::Exe seems strange to me. Could it be something else entirely? For example, when you are building PAR-Packer, do parl.exeб parldyn.exe and static.exe have icons? It looks to me that your build fails because you don't have resource section in your executables, which would suggest your executables weren't linked against win32.coff... Also, what is your perl -V?
Subject: Re: [rt.cpan.org #54074] PAR test fails a gui test with Win32/Exe.pm
Date: Wed, 03 Feb 2010 08:14:45 -0500
To: bug-PAR-Packer [...] rt.cpan.org
From: Malcolm Nooning <m.nooning [...] comcast.net>
perl -MWin32::Exe -e "print \"$Win32::Exe::VERSION\n\" 0.11 Show quoted text
> do parl.exe? parldyn.exe and static.exe have icons?
Yes, but, um, not special ones. They show the same windows icons as any ".exe" file. For comparison purposes, they are the same as the icons that Windows gives C:\perl\bin\a2p, and C:\perl\bin\perlglob. Same with C:\temp\PAR-Packer-1.002\myldr\par is the same, too. Show quoted text
> linked against win32.coff
How would I check for this? C:\>perl -V Set up gcc environment - 3.4.5 (mingw special) Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=MSWin32, osvers=5.00, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='C:/MinGW/bin/gcc.exe', ccflags ='-DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -DHASATTRIBUTE -fno-strict-aliasing -mms-bitfields', optimize='-O2', cppflags='-DWIN32' ccversion='', gccversion='3.4.5 (mingw special)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='C:\MinGW\bin\g++.exe', ldflags ='-L"C:\Perl\lib\CORE"' libpth=\lib libs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lmsvcrt perllibs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lmsvcrt libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -L"C:\Perl\lib\CORE"' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_SITECUSTOMIZE Locally applied patches: ActivePerl Build 1006 [291086] 32728 64-bit fix for Time::Local Built under MSWin32 Compiled at Aug 24 2009 13:48:26 @INC: C:/Perl/site/lib C:/Perl/lib . C:\>
From: snaury [...] gmail.com
On Wed Feb 03 08:15:48 2010, m.nooning@comcast.net wrote: Show quoted text
> cc='C:/MinGW/bin/gcc.exe'
Aha! You see, here's your problem. myldr/Makefile.PL checks for $cc being /^gcc\b/i and your $cc clearly doesn't start with gcc. You need to either rebuild Perl so that cc is not absolute, or ask Steffen Muller to check basename of $cc...
Subject: Re: [rt.cpan.org #54074] PAR test fails a gui test with Win32/Exe.pm
Date: Wed, 03 Feb 2010 16:43:55 -0500
To: bug-PAR-Packer [...] rt.cpan.org, "par [...] perl.org" <par [...] perl.org>
From: Malcolm Nooning <m.nooning [...] comcast.net>
You suggested writing to Steffen Muller to check the basename of $cc because, to restate the problem, I cannot by hand do pp --gui --icon hi.ico -o hello.exe hello.pl because my MinGW's cc is not /^gcc\b/i, which is what is looked for. This also causes the 31st of the t/20-pp.t test file to fail, which is the same thing I am trying to do by hand above. My cc is not necessarily gcc, either, as I use a Microsoft compiler sometimes, too. I am sure others do, too. Recompiling ActiveState perl to get a module to work does not seem the way to go. Steffen, can you alter the Par::Packer code to check what cc is in use? My Windows XP ActiveState Perl 5.10.1 gets the error Can't call method "remove" on an undefined value at C:/Perl/site/lib/Win32/Exe.pm line 220, as reported in the rt bug. Thanks On 2/3/2010 3:54 PM, Alexey Borzenkov via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=54074> > > On Wed Feb 03 08:15:48 2010, m.nooning@comcast.net wrote: >
>> cc='C:/MinGW/bin/gcc.exe' >>
> Aha! You see, here's your problem. myldr/Makefile.PL checks for $cc being /^gcc\b/i and your > $cc clearly doesn't start with gcc. You need to either rebuild Perl so that cc is not absolute, or > ask Steffen Muller to check basename of $cc... > >
Subject: Re: [rt.cpan.org #54074] PAR test fails a gui test with Win32/Exe.pm
Date: Wed, 03 Feb 2010 17:39:20 -0500
To: bug-PAR-Packer [...] rt.cpan.org, "par [...] perl.org" <par [...] perl.org>
From: Malcolm Nooning <m.nooning [...] comcast.net>
Here is a fix for the "Can't call method "remove" on an undefined value " problem. Change line 106 of myldr/Makefile.PL to what you see below. } elsif ( ($cc =~ m/^gcc\b/i) or ($cc =~ m/\bgcc.exe\b/i) or ($cc =~ m/^cc\b/i and $gccversion)) { This, along wiht Alexey's other patch for commenting out if ($Config{_delim} eq '\\') { s{\\}{/}g for @inc } in script/par.pl, results in all tests passing on Windows XP, ActiveState 5.10.1. Thanks
Cf #55994, fixed in 1.005 (and Win32::Exe) Cheers, Roderich