Mon Jun 29 15:49:22 2015: Request 104635 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: IO error the first time an executable built by the packer is run
on OSX
Broken in: 1.025
Severity: (no value)
Owner: RSCHUPP
Requestors: mschi...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104635 >
On 2015-06-26 04:56:15, RSCHUPP wrote:
> OK, time for some code exegesis...
Perhaps the bug is not in PAR::Packer, but rather in Module::ScanDeps
(which is used by PAR::Packer to determine what modules etc to "pack in").
$ scandeps.pl -V eg/foo
# Foo.pm [module]
# Foo/Bar.pm [module]
# foo [data] <--- ???
# Legend: [C]ore [X]ternal [S]ubmodule [?]NotOnCPAN
'Foo::Bar' => '0', # ? # Foo
'Foo' => '0', # ? # foo
But when I move foo to the cwd:
$ scandeps.pl -V foo
# Foo.pm [module]
# Foo/Bar.pm [module]
# Legend: [C]ore [X]ternal [S]ubmodule [?]NotOnCPAN
'Foo::Bar' => '0', # ? # Foo
'Foo' => '0', # ? # foo
also
$ scandeps.pl -V ./foo
# Foo.pm [module]
# Foo/Bar.pm [module]
# foo [data] <--- ???
# Legend: [C]ore [X]ternal [S]ubmodule [?]NotOnCPAN
'Foo::Bar' => '0', # ? # Foo
'Foo' => '0', # ? # foo
The line "# foo [data]" is probably responsible for the spurious zip member
lib/foo:
$ pp -o good.exe foo
$ unzip -l good.exe
Archive: good.exe
Length Date Time Name
--------- ---------- ----- ----
0 2015-06-29 21:42 lib/
0 2015-06-29 21:42 script/
455 2015-06-29 21:42 MANIFEST
215 2015-06-29 21:42 META.yml
80 2015-06-29 21:42 lib/Foo.pm
71 2015-06-29 21:42 lib/Foo/Bar.pm
55 2015-06-29 21:42 script/foo
676 2015-06-29 21:42 script/main.pl
--------- -------
1552 8 files
Note: no lib/foo!
To be continued.
Cheers, Roderich
