Wed Aug 26 10:01:41 2009: Request 45403 was acted upon.
Transaction: Correspondence added by SMUELLER
Queue: PAR
Subject: Program too big to fit in memory
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: richard....@freescale.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=45403 >
Hi Richard,
apologies for the delay in replying.
On Fri Apr 24 15:28:19 2009, richard....@freescale.com wrote:
> I'm running PAR & pp on Windows XP to generate a standalone .exe.
> Resulting .exe runs on a different computer just fine, but gives a
> "Program too big to fit in memory" error on another. Both computers are
> running XP as well with at least 1GB RAM. Am running ActivePerl 5.10.0
> Build 1004.
Is this a 32 vs. 64bit issue?
> The test script is short:
[snip test script]
This is very, veeeery likely not at all related to your test script.
> I've tried pp -m option without any success. I also tried the
> evaluation version of perl2exe with no success.
>
> I have verified the paging file on both computers and they are bigger
> than the 384MB I have. I have also tried running the .exe in
> compatibility mode with no success. There doesn't appear to be any
> differences for autoexec.nt and config.nt.
>From my very distant and limited experience with Windows, you get
similar errors if you try to run an executable that was not generated
for the platform at hand. Actually, I wouldn't even be surprised if you
could simply rename an arbitrary file to an .exe and run it to get the
same error.
I'll wager that this is not even a PAR bug at all but simply
non-binary-compatible systems (and thus marking the bug as rejected, but
feel free to reply with more input: It will be automatically reopened!
The history of the ticket is NOT erased either!)
This is supported by the fact that the entirely unrelated perl2exe tool
produces the same problems.
As an extra test, you can copy the parl.exe PAR loader from the source
to the target machine and try running it. If it doesn't run, you at
least know that your perl code is not at all involved in the issue, but
that it's a problem with the binary/C/loader part of the tool chain.
Cheers,
Steffen
