develooper Front page | perl.par | Postings from May 2008

Re: Archive::Unzip::Burst on Win32

Thread Previous | Thread Next
From:
Mark Dootson
Date:
May 16, 2008 15:02
Subject:
Re: Archive::Unzip::Burst on Win32
Message ID:
482E04B8.2090300@znix.com
Hi,

I got around to testing PAR::Packer build on Linux too, where it fails the same test.
Just a heads up.

Mark

Mark Dootson wrote:
> All,
> 
> A couple of issues have arisen so far with Archive::Unzip::Burst on Win32.
> 
> If I build PAR::Packer when Archive::Unzip::Burst is already installed 
> (and therefore Archive::Unzip::Burst ends up in the PAR::Packer test 
> execs ) then I fail test t/20-pp.t 33. This is testing the -a option. I 
> shall investigate and try to figure out reason. It's probably something 
> to do with file packed as -a already being extracted. Output from 
> failing build pasted at end of mail in case anyone can spot anything 
> obvious. Is this a Win32 only problem?
> 
> The second issue is that PAR.pm as it stands doesn't really make best 
> use of an archive extracted by Archive::Unzip::Burst. For example, I 
> started to test extract times for a Wx script - a good mix of large dll 
> files and all the utf8 and posix stuff gets packaged too.
> 
> I don't see improvements because, of course, Archive::Unzip::Burst 
> extracts all the Wx dlls to ../shlib/archname, then PAR uses 
> Archive::Zip to extract them again from the zip to the root of 
> $ENV{PAR_TEMP}.
> 
> So, PAR.pm needs amending so that read_file etc recognises that 
> Archive::Zip isn't needed and we get shlibs on PATH / LD_LIBRARY_PATH etc.
> 
> I think it is simple enough to store how each par file in @LibCache was 
> extracted and act accordingly. However, the shlib question is more 
> difficult. Adding ../shlib/archname to the paths is a possibility - 
> however, I tend to think that to maintain compatibility with existing 
> behaviour and to honour the 'no_shlib_unpack' option of PAR::import, 
> when a par file has been extracted with Archive::Unzip::Burst, PAR 
> should copy the contents of $ENV{PAR_TEMP}/shlib/archname to 
> $ENV{PAR_TEMP}/ when 'no_shlib_unpack' => 0 and do nothing when 
> 'no_shlib_unpack' => 1.
> 
> Just thought I'd report initial issues using Archive::Unzip::Burst.
> 
> 
> Regards
> 
> Mark
> 
> #   Failed test 'pp_test_small_minus_a
> t/20-pp.................NOK 33/34# [430]
> # Test 32_9 The command string " hello.exe " in directory 
> C:\PAR\build\mingw\PAR-Packer-0.980\contrib\automated_pp_test\pp_switch_tests\ 
> 
> temp2,did not produce :: "hello" ::
> # Instead, it produced :: Could not unzip into 
> 'C:\DOCUME~1\MARKDO~1\LOCALS~1\Temp\par-Mark_Dootson\cache-19e0427425d6bdd2de70a37172a8635e9c 
> 
> 97df27/inc'. Error: No such file or directory at 
> C:/BasePerl/perl510/site/lib/PAR.pm line 577.
> # warning:  stripped absolute path spec from 
> /PAR/build/mingw/PAR-Packer-0.980/contrib/automated_pp_test/pp_switch_tests/temp2/text 
> ::
> # End of [430] results
> #
> # Did pp -o hello.exe -a 
> "C:/PAR/build/mingw/PAR-Packer-0.980/contrib/automated_pp_test/pp_switch_tests/temp2/text;/PAR/build/mingw/ 
> 
> PAR-Packer-0.980/contrib/automated_pp_test/pp_switch_tests/temp2/text" 
> hello.pl produce hello.exe?
> # '
> #   at automated_pp_test.pl line 8492.
> t/20-pp.................ok 34/34# Looks like you failed 1 test of 34.
> t/20-pp.................dubious
>        Test returned status 1 (wstat 256, 0x100)
> DIED. FAILED test 33
>        Failed 1/34 tests, 97.06% okay
> t/30-current_exec.......# Please wait
> t/30-current_exec.......ok
>        1/4 skipped: various reasons
> Failed Test Stat Wstat Total Fail  List of Failed
> ------------------------------------------------------------------------------- 
> 
> t/20-pp.t      1   256    34    1  33
> 
> 
> Steffen Mueller wrote:
>> Hi Mark, hi list,
>>
>> Mark Dootson wrote:
>>> Attached is patch against Archive-Unzip-Burst-0.02_01 which seems to
>>> work with both VC6 and MinGW.
>>> If anyone would like to test, that would be good.
>>>
>>> It is a direct lift from the info-zip dll usage example, although
>>> objects are linked into Burst.dll rather than linking to an extenral
>>> unzip32.dll.
>>
>> Awesome! I don't have a win32 to test on, but I checked that Linux still
>> works with the patch applied. In fact I already committed it to trunk so
>> people can try it more easily. We can always revert if breakage occurs.
>>
>> Thanks a lot for fixing this!
>>
>> Best regards,
>> Steffen
> 
> 



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About