sisyph...@optusnet.com.au wrote:
-----Original Message----- From: bulk88
Sent: Friday, January 09, 2015 4:16 PM
To: module-authors@perl.org ; perl5-port...@perl.org
Subject: name for a Module to build XS with Visual C on a core Mingw GCC
Perl
ActivePerl in 5.16 and before had code to build XS modules with
dmake/mingw/gcc, while the perl core was compiled with Visual C.
The same could also be achieved using ExtUtils::FakeConfig.
Too late, I reimplemented it.
Going the other way, Visual C extensions with a GCC core has never
been done.
I thought that ExtUtils::FakeConfig would be able to accommodate that,
too. However, I could be wrong about that. It was certainly written
mainly so that its author could use dmake/mingw with msvc6-built
ActivePerl.
Looking through its tarball, you are right, it only includes profiles to
go from VC core to GCC XS.
I've managed to get 1 XS module to compile and run with a VC XS DLL
and a GCC Perl interp DLL and a couple things XSUBs ran flawlessly. So
what should be the name of this module? "VCConfig" in the root
namespace? Win32::VCConfig? Win32::Config?
Win32::VCConfig sounds good to me if you don't want to venture into the
ExtUtils::FakeConfig namespace.
I want less to type. I am not sure yet if I need to install it as
site/lib/Config.pm. EUMM distros works fine with -MVCConfig, I haven't
tried Module::Build distros, so I'm not sure if I will have to resort to
site/lib/Config.pm yet. Also config.h will need a 1 line patch or to be
replaced with site/lib/CORE/config.h since there is 1 setting in it that
syntax errors on VC.
Bear in mind that the mileage that the msvc6-built ActivePerls achieved
with MinGW was attributable to both MSVC-6 and MinGW using the same
runtime (msvcrt.dll).
If different runtimes are used (as might happen with your
other-way-about configuration) then you can run into problems - eg when
a handle that has been created by one runtime gets passed to the other
runtime (whereupon the "other" runtime says "wtf is this ?" and promptly
crashes).
From memory, Win32::SharedFileOpen was unusable if the compiler that
built it used a different runtime to that used by perl.
That would be a coding mistake that is easy to fix if you have all the
source code available. Use perl exported win32_*() functions, not c std
lib (MS CRT) functions. That guarantees you are using the same CRT as
perl even if you/your compiler doesnt know the name of that CRT or what
it is. Also Perl [annoyingly] hooks most of CRT, and all of stdio with
CPP macros, from the code inside XSUB.h. I have never personally seen
any negative effects from multiple CRTs in 1 perl process/XS module
being a different CRT from core's CRT. Of course for L2 caching reasons,
multiple CRTs are bad, but many apps (try firefox) will have multiple
CRTs inside for various reasons.
