Hi,
PAR::Packer executables are really just zip files on steroids.
So Perl510.dll et al get extracted and execute from temp directories at run
time.
Static linking - now that you know that a PAR exec is just a zip, I guess your
question would be 'can I wrap everything up in the zip' to which the answer is
yes EXCEPT for anything the external par.exe itself is linked against. So, if
you had a module compiled with MSVC2005 you could just wrap MSVCR90.dll in the
par exec.
Anyway, the short answer to avoid an extra C/C++ runtime is use VC6 or MinGW -
you might still end up having to use a module compiled with VC7 /8 /9.
This would be the case if the module author only targetted those compilers and
you weren't in the mood to learn how to 'fix' the code to work with VC6 /MinGW.
But you just ahve to add the appropriate runtime to the PAR.
By forcing you to distribute MSVCR90.dll with your app and install it to an application directory, MS avoids having to cope with version conflicts between, say, MSVCR90.dll original and MSVCR90.dll service pack 2. In the world of MSI installers and huge storage media, this is probably a good idea.
Nice work with the wiki entry.
Regards
Mark
Yuval Levy wrote:
So, here is my promised write up - correct me if I am wrong:
<http://wiki.panotools.org/Install_Panotools-Script_on_Windows#Infrastructure_to_build_the_.exe_tools_-_the_new_way>
I went the MinGW way (thank you, Mark!).
Jan Dubois wrote:
Setting of ccversion will be done automatically (at runtime) in
ActivePerl build 823
(whenever 5.8.9 gets released) and in 1003 (probably out next week).
I may try this one at a later stage.
I would recommend using either VC++ 6 or MinGW to build Perl modules,
and especially
PAR binaries because these 2 compilers use MSVCRT.dll as the C runtime
library, and
this library is part of the OS, so there is no need to deploy it with
your application.
If you compile any module with VC 2008, then you will always have to
include MSVCR90.dll
with your applications too because it may not be present on a target
machine.
that's quite an important detail. can anybody explain to me why
Microsoft amputates its own O/S and does not include MSVCR90.dll?
and (correct me if my language is not precise, I'm a caveman) is there a
way to bring statically linked Perl modules that don't need any of these
dll?
the current ("legacy"/undocumented) way to ship compiled Perl modules
with hugin is to bundle perl58.dll. I see with great pleasure that this
is no longer necessary with PAR::Packer - my hello world test seems to
run without it?
thanks a lot again!
Yuv
