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