----- Original Message -----
From: "Erland Sommarskog" <esq...@sommarskog.se>
To: <perl-xs@perl.org>
Sent: Wednesday, August 03, 2011 7:44 AM
Subject: Re: Problem with building XS module on AS 1401
"Sisyphus" (sisyph...@optusnet.com.au) writes:
If your 32-bit perl, and therefore also your binaries, use a runtime
other than msvcrt.dll (eg msvcr80.dll), then that also can cause *big*
problems - in the form of a crash. ActivePerl uses the msvcrt.dll
runtime, and that runtime won't know what to make of any handles passed
to it that were created by a different runtime. If that's happening with
your 32-bit builds, then the only solution I know of is to use a
compiler (and a perl) that *does* use the msvcrt.dll runtime - eg MSVC++
6.0 or MinGW (and a perl built with the same).
It occurred to me that I use the /MT option to compile the MSVCRTnn dll
statically. I tried removing that option. No change. But then I realised
I had defined CCFLAGS for another option as well. Removed that. And
that turned the tables. To the worse, since linking now failed with
tons of errors referring to the C Run-time library.
If that is the problem, I would also think you would then get the same
issue with earlier versions of ActivePerl. Did that happen ?
No. And it does not occur with ActivePerl 64-bit.
Does the problem arise only when you use *ActivePerl* with your compiler
to build your module ?
So far, yes.
Do you get a similar problem if you take the binaries that tested fine on
*your* build of perl-5.14.1, and use them with ActivePerl-5.14.1 ?
I've yet to test that. But if the problem is the mix of MSVCRT versions,
this should not help.
True. But if those binaries *do* work fine with ActivePerl-5.14.1 then the
problem is probably *not* the mixing of runtimes.
Of course, the fact that it happens only with the 32-bit perl-5.14 suggests
that it's something else, anyway - and you may well be on the right track by
investigating the compilation flags. (Have you tried a different
optimization ?)
Cheers,
Rob
