On Sat, Jun 15, 2019 at 11:49 AM Oliver Betz <list...@gmx.net> wrote:
> On Fri, Jun 14, 2019 at 8:40 PM welle ozean via par <par@perl.org> wrote:
>
By the way, why is the application trying to call something in
> "Users/we/perl5/perlbrew" which is a path in the machine where I
> compiled the application?
>
>
> this is likely a problem of the Perl distribution you are using.
>
>
No. Some "packed" modules that are extracted with mangled names (like
1a40c6f9.pm) have #line directives that carry their original file name
(i.e. on the packer's machine).
(If you must know, these are the modules packed into the "FILE" section,
see "Anatomy of a Self-Contained PAR executable" in PAR::Tutorial.)
Otherwise die() etc messages involving these modules would be useless.
These include all dependencies of Archive::Zip (including several
IO::Compress::* modules and core modules like IO). Nothing to worry about.
(OTOH you should worry about modules with paths that could only have come
from the machine where the executable is run as these indicate a failure to
pack all dependencies and also a failure of PAR to contain all module
loading to packed modules only).
Am Sa., 15. Juni 2019 um 03:11 Uhr schrieb Shawn Laffan <
shawnlaf...@gmail.com>:
> Also, the code you gave does not look correct. It is using the numeric
> not-equals operator to compare $retVal against a string.
> Is this from your code or within Tk?
>
>
The code
> "if {$catchVal != 0} {
> if { $retVal != "_TK_BREAK_\n" } { # BREAK returns
> are not errors
> return..."
>
probably is Tcl, not Perl :) The script is using Tcl::pTk which binds Perl
to a native Tcl and Tk installation (different from Tk
<https://metacpan.org/release/Tk> which is native Perl with XS code derived
from the C source of Tcl/Tk).
BTW, that means you would have to pack the native Tcl and Tk DLLs, too -
didyou?
Cheers, Roderich
