Tue Aug 11 05:19:48 2009: Request 48614 was acted upon.
Transaction: Ticket created by rovf
Queue: PAR
Subject: PAR must NOT evaluate PERL5OPT
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: yn...@mm.st
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=48614 >
If I execute an exe file created by PAR, in an environment which happens
the variable PERL5OPT set to a string containing -Mxxx for any module
xxx, the program aborts with "Can not find xxx in @INC", even if xxx is
a standard module (such as strict, warnings, or File::Basename).
The reason can be explained in that by creating the EXE file, @INC is
set to the empty list, and when PERL5OPT is evaluated, the module can't
be resolved.
IMO, it doesn't make sense to honor PERL5OPT in a compiled program,
because most Perl command line switches are meaningless in this context
anyway.
We create EXE files out of Perl files, not only to hide the sources, but
also to make them insensitive to the environment they are running in,
and oblivious to whether or not a Perl version is installed on the
target host, and which version it is. If execution of the exe file can
easily be broken by just setting PERL5OPT, we are loosing the
flexibility which we hoped to gain from PAR.
A fix would be to have the EXE file ignore PERL5OPT.
It seems that perl2exe is doing it in that way, because if I compile my
Perl program with perl2exe, the error does not occur.
