On Wed, May 28, 2008 at 8:24 PM, Henry Wu <[EMAIL PROTECTED]> wrote: > More information, > > when environmental variable PERL5LIB has some value. for exmaple > C:/user/perl/lib > > I put print "INC [EMAIL PROTECTED]"; in my perl script and build > abc.exe. > When I run abc.exe I got the following results: > > INC > =C:\WINDOWS\TEMP\par-user234\cache-4cd99632dfdc54373502468518cbf1937587a68e\inc\lib > C:\WINDOWS\TEMP\par-user234\cache-4cd99632dfdc54373502468518cbf1937587a68e\inc > CODE(0xf15dbc) CODE(0xf15fa8) > > The value in PERL5LIB did not show in @INC, but when I run the abc.exe > on some users' machine, the following error shows: > > IO object version 1.21 does not match bootstrap parameter 1.23 at > C:/programs/Perl/lib/DynaLoader.pm line 252. > ... > ======================================= > when I remove PER5LIB environmental variable, the abc.exe runs well on > all users' machine. > > So I guess the PERL5LIB is in effect when abc.exe tries to extract > itself for the first time. That extracting code failed because of > PERL5LIB value. So the perl code failed before the exe file can > expand itself and before the final perl script run.
Good point. I ran the above example (on Solaris) under truss and indeed saw stat() and open() system calls referencing directories included in PERL5LIB, most likely in the early extraction phase. However, even with that knowledge I wasn't able to reproduce your problem, since all modules or shared libraries that the executable was looking for had names like d1d8f65d.pm or d1d8f65d.so, so couldn't conflict with "real world" stuff like IO/Handle.pm. But that may be due to different PAR or PAR::Packer versions or Unix vs Windows. Cheers, Roderich
