On Sat, 19 Dec 2009, Sisyphus wrote:
>
> I had long considered my MinGW-built perl 5.10 (and Strawberry Perl
> 5.10) to be binary compatible with ActivePerl 5.10, and have only just
> discovered in the last few days that I was wrong - because ActivePerl
> is compiled with the -mms-bitfields flag, but my MinGW-built perl and
> Strawberry Perl are not.

ActivePerl is *not* compiled with the -mms-bitfields flag; it is only put into the CCFLAGS by ActivePerl if you want to compile an XS module with GCC. The -mms-bitfields is a pure GCC flag that tells it to layout bitfields inside structs the same way VC does. Without that flag VC and GCC don't create binary compatible code (if the code uses bitfields).

> It's an incompatibility that doesn't bite often. The only instance I
> have so far come across is in relation to GIMME_V - you can see the
> full story at http://www.perlmonks.org/index.pl?node_id=813362 .
>
> Assuming that ActiveState are using this flag for good reasons, I'm
> led to wonder if it should be a *default* inclusion in the perl source
> win32/Makefile and win32/makefile.mk. Some care would be needed - eg
> Borland regards the flag as a fatal error, so the flag needs to be
> kept invisible to that compiler. My MSVC++ 7.0 compiler (and,
> presumably, later versions of MSVC++) doesn't understand the flag
> either, but at least it just issues a warning and ignores the flag.
> (Even so, this could make for a very noisy build of perl with the
> "later" MS compilers - I haven't actually checked to see just how
> noisy it is.)

As I mentioned above, the flag should only be used for GCC. I don't care about compatibility with the ancient Borland compiler, so I don't know if it will lay out bitfields the same way as VC.

And starting with Perl 5.11 the flag is being set in win32/makefile.mk already. The problem is that I did not detect this incompatibility between VC and GCC until after 5.10 was already shipped. Therefore it was too late to include it in 5.10.1: It would make the 5.10.1 build incompatible with a 5.10.0 build compiled with the same compiler, a situation that is clearly undesirable.

> May be we should instead include the flag in those two win32 makefiles
> as an option ("off", by default) ?
>
> I notice that there's currently no mention at all about this flag in
> the README.win32 - perhaps this should be addressed by someone who
> understands the reasons for employing it ? (I'll see if I can google a
> clear and concise description of the reasons that one might want to
> employ this flag.)
>
> Finally, and this relates only to ActivePerl (and is therefore OT
> here), I notice that earlier versions of ActivePerl-5.8.x were
> compiled *without* the flag, but it's present in ActivePerl-5.8.9.
> Seems to me an ill-advised thing to do (given what I have just
> learned), though I don't have an instance of this actually causing any
> problems. (The GIMME_V problem is restricted to 5.10, even though the
> very same -mms-bitfields disparity applies to 5.8.9.)

Note that ActivePerl as a *distribution* has the additional feature that it support building of XS extensions with GCC even when the core Perl is being compiled with the OS vendor compiler (VC for Windows). So adding this flag actually fixes a compatibility issue for ActivePerl. Extensions that had been built with GCC outside the ActivePerl::Config setup were already incompatible with the VC builds, and there is nothing that could be done to fix that (except encouraging others to always use the -mms-bitfields option). So I'm not sure what was "ill-advised" about this compatibility *fix*.

I talked with both AdamK and CSJewell about this issue regarding Strawberry Perl 5.10.x, and both weren't really concerned too much about that issue (it is potentially a problem to install modules from ActivePerl PPM repositories into Strawberry Perl if the code accesses bitfields).

Given that 5.11 already contains the -mms-bitfields option for GCC in win32/makefile.mk the problem will be gone for Perl 5.12 builds.

> Thoughts ?

See above. I don't think there is any outstanding action item with regards to this issue, but feel free to let me know if you think I missed something. And please update the PerlMonks thread with this information, if you have the time!

Cheers,
-Jan