From:	bob davis	Date:	Sat Aug 16 13:03:15 2008
Subject:	Re: perl5lib

Well I was hoping the experts :-) would take it from here.
For my purposes it would fine because I would just patch my installation 
and all my exe's would work that way.

Roderich Schupp wrote:
> On Fri, Aug 15, 2008 at 11:36 PM, Bob Davis <bob@bobsbits.net> wrote:
>   
>> It seems that if PERL5LIB is set then the exe generated from pp doesnt work
>> on the target client. This happens in particular when oracle is installed on
>> the client. This was discussed in  another thread and it was suggested that
>> a pp switch be added to ignore PERL5LIB. So I decided to hack it and found
>> the place in util.c which is under myldr.
>>
>> Here is patch diff
>>     
>
> That's the easy part :) But now you _always_ ignore PERL5LIB, because
> the stuff in myldr is built once when PAR::Packer is built and then included
> "as is" in every pp-packed executable.
> The real solution is to add another switch to pp (also easy) and to
> communicate that setting somehow into myldr/util.c.
>
> The tricky part is "somehow". pp generates slightly different main.pl
> scripts (embedded in the packed executable) depending on its options,
> but unsetting PERL5LIB in main.pl doesn't have any effect, because
> PERL5LIB is added to @INC in the perl startup code _before_ main.pl
> starts executin. You can pass information in environment variables from
> myldr/util.c to e.g. main.pl, but not vice versa.
>
> Idea:
> - in myldr/util.c: if PERL5LIB is set, save it to PAR_PERL5LIB,
>   then unset PERL5LIB
> - insert (very early) on into main.pl (dependent on your new pp option)
>
>     unshift @INC, split($Config{path_sep}, $ENV{PAR_PERL5LIB}) if
> $ENV{PAR_PERL5LIB};
>
> Note that this still changes the current behaviour, because PERL5LIB is now
> unset during the early extraction of modules.
>
> BTW, I also stumbled about Oracle installations setting PERL5LIB for everyone
> and found that very annoying :(
>
> Cheers, Roderich
>