| Subject: | parldyn uses win32.dll from external environment for _set_par_temp |
parldyn.exe loads Win32's dynaloader DLL from the host environment (or
fails to run if it's not found), even though it also embeds a copy. This
happens because par.pl accesses Win32::LoginName in _set_par_temp,
causing the module to load before PAR::Heavy::_init_dynaloader has had a
chance to patch the import.
parl.exe does not exhibit this problem because it sets up the temp dir
in C code (to extract static.exe and perl58.dll), so $ENV{PAR_TEMP} is
already set and _set_par_temp returns early without accessing Win32.
I'm not really sure what the right fix is; one can't call
PAR::Heavy::_init_dynaloader, because PAR::Heavy isn't extracted yet
either (and can't be, since we're still trying to create the temp dir).
If I arrange things so that it finds the system PAR::Heavy, it runs and
loads the right Win32.pm, but later dynaloads fail; somehow it's not
calling the overridden dl_findfile. I'm not quite sure why that would
be, but the fact that it loaded the wrong copy of PAR::Heavy (and did so
before PAR was done initializing) seems like sufficient nastiness that
I've not pursued it any further
If I comment out the Win32::LoginName bits, it works correctly (it uses
$ENV{USER} instead).
PAR::Packer 0.970 worked for me here, but that was with ActiveState
5.8.8.819(Win32.pm 0.35) instead of StrawberryPerl 5.8.9 (Win32.pm
0.39). It looks like ActiveState does not autoload the Win32 dll for
Win32::LoginName and StrawberryPerl does. I'm not sure why this would be
the case, since I have no idea how the autoload magic for [CORE] Win32
functions works.
This was a contributing factor to mis-reporting #45045, and was (I
think) the real root cause of my dynamic builds not working. Having it
use the system perl58 just meant it was able to find the system Win32.pm
and DLL, which masked the problem (on my machine)