Or, As I understand it slightly better...... :-)
adding require Win32; to the require_modules sub in par.pl means that Win32.pm gets extracted on startup along with Archive::Zip et al, it gets required and loaded by the stub, so when Win32::GetCwd is called the Win32.dll is loaded. At that time, the \par-logname\cache-...\inc directory has not been created nor are any modules outside the require_modules sub list available. Mark Dootson wrote: > Hi, > > As I understand it ...... > > The dependency on Win32::GetCwd is in par.pl - which becomes part of any > packed exec. > Win32::Cwd is needed by par.pl before there is any hook in @INC and before > anything is extracted using Archive::Zip. > > Win32::GetCwd is in perl58.dll. However, in AS 820 (and the next versions of > perl 5.x.x), the call to Win32::GetCwd is forwarded to the Win32.dll. The > Win32 module is loaded implicitly. > > So, in the pp'd exec, the exec stub, perl58.dll and all the modules in > 'require_modules' are extracted. This is not done via Archive::Zip. > > When 'par.pl' is run, all that is in @INC is '.' - which is the directory > where the 'require_modules' live. When the Win32::GetCwd call is made at this > time, Win32.dll is not available. It as not been 'pre extracted'. IF the > perl58.dll that has been loaded is the AS 820 one, then the Win32::Cwd call > will fail because there is no Win32 module available to implicitly load(it > has not been extracted). > > The par.pl code checks 'if defined(&Win32::GetCwd)' - which succeeds because > it is in perl58.dll. The call to Win32::GetCwd() then fails, because it > cannot load Win32.dll. Perl versions prior to AS 820 did not load Win32.dll > but handled Win32::GetCwd() entirely within perl58.dll itself. > > So, if you want to use Win32::GetCwd, then Win32.dll must be extracted before > you call Win32::GetCwd, in which case, Win32 must be added to the > 'require_modules' list. Perhaps to clarify, 'require_modules' is a list of > modules in par.pl that must be extracted first to allow all the @INC hook and > Archive::Zip stuff to work. > > > > Regards > > Mark > > > m.nooning wrote: >> I am wondering if we are going astray here. My installation of PAR/PP >> (0.70) worked just fine with AS 5.8.8 build 820 when I first did a test >> of "pp -o hello.exe hello.pl". My only change was to install the 0.73 >> versions of PAR and pp, and Autoloader, and now @INC is empty (except >> for .). I was thinking that the executable that pp created cannot find >> Win32 because it's @INC is empty. I thought that if hello.exe's @INC >> could get back it's paths to the extracted files and libs ( >> ...\par-logname\cache-... ), it would find the Win32 that had been >> extracted to there. >> >> Or maybe my lack of knowledge is preventing me from keeping up with the >> conversation. >> >> >> > >
