Skip Menu |
 

This queue is for tickets about the PAR-Packer CPAN distribution.

Report information
The Basics
Id: 45071
Status: open
Priority: 0/
Queue: PAR-Packer

People
Owner: Nobody in particular
Requestors: puetzk [...] puetzk.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.991
Fixed in: (no value)



Subject: parldyn uses win32.dll from external environment for _set_par_temp
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain
Charset: utf8
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1833
Download (untitled) / with headers
text/plain 1.7k
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)
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Charset: utf8
Content-Type: text/plain
Message-ID: <rt-3.6.HEAD-2538-1239849627-621.45071-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 739
Download (untitled) / with headers
text/plain 739b
Show quoted text
> 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.
I found perldoc Win32CORE (which lead me to http://www.nntp.perl.org/group/perl.perl5.porters/2007/06/msg125741.html), which was a bit enlightening on how this works; it looks like this is probably a perl 5.9 change (that was backported to 5.8.9?), and the Win32 [CORE] functions now autoload Win32.pm, whereas they used to be statically linked into perl58.dll.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.