Tue Jun 01 05:01:25 2010: Request 57948 was acted upon.
Transaction: Correspondence added by SMUELLER
Queue: PAR-Packer
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and
a missing dependency libgcc_s_sjlj-1.dll
Broken in: (no value)
Severity: (no value)
Owner: RSCHUPP
Requestors: m...@iki.fi
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57948 >
RSCHUPP via RT wrote:
> Queue: PAR-Packer
> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57948 >
>
> On Sun May 30 08:20:47 2010, mark.doot...@znix.com wrote:
>> I don't think you can mix and match your linking model on Windows. So if
>> you had a static perl.exe (or par.exe) you could not then load separate
>> xs code dynamically - you would have to compile in all the xs modules
>> you require. That's why, by default, you don't get a static perl built
>> on MSWin. It is not generally useful.
>
> Thanks for the explanation, Mark.
> I'll hold my nose and try the "load_me_3" approach then, stay tuned.
Hey, I survived modifying the load_me stuff, too! But I probably have
lower standards :)
More seriously, I'm pretty sure you already know how it works, but it's
just a vehicle of embedding an arbitrary file as a variable in C code &
extracting it when run. I believe I refactored some of it to be slightly
less insane a few years back. It's still totally a kludge, but alas, I
don't have a good idea of how we could work around it. Except that
statically linking a libz for some minor compression and reduction of
the executable file size would be really cool. Not saying *you* should
do that, mind you.
Cheers,
Steffen
